aboutsummaryrefslogtreecommitdiffstats
path: root/actionpack/test/dispatch/prefix_generation_test.rb
Commit message (Collapse)AuthorAgeFilesLines
* call the routes method on enginesAaron Patterson2014-08-051-74/+37
| | | | if we access the instance, we can free up lots of codes
* a rails application should be an engine subclassAaron Patterson2014-08-051-1/+1
|
* no reason to lazily instantiate the routesAaron Patterson2014-08-051-45/+42
| | | | | especially if you're just going to add a call two lines down that populates the cache. common.
* just assign the instance variables on the testAaron Patterson2014-08-051-7/+3
|
* Rails-ish apps should descend from Rails::RailtieAaron Patterson2014-07-161-1/+2
| | | | | Use an is_a check to ensure it's a Railsish app so we can avoid respond_to calls everywhere.
* this class is a model, so it should act like oneAaron Patterson2014-05-121-0/+3
|
* Allow engine root relative redirects using an empty string.Andrew White2014-01-011-41/+111
| | | | | | | | | | | | | | | | | | Example: # application routes.rb mount BlogEngine => '/blog' # engine routes.rb get '/welcome' => redirect('') This now redirects to the path `/blog`, whereas before it would redirect to the application root path. In the case of a path redirect or a custom redirect if the path returned contains a host then the path is treated as absolute. Similarly for option redirects, if the options hash returned contains a `:host` or `:domain` key then the path is treated as absolute. Fixes #7977
* Respect `SCRIPT_NAME` when using `redirect` with a relative pathAndrew White2013-10-101-0/+100
| | | | | | | | | | | | | | | | Example: # application routes.rb mount BlogEngine => '/blog' # engine routes.rb get '/admin' => redirect('admin/dashboard') This now redirects to the path `/blog/admin/dashboard`, whereas before it would've generated an invalid url because there would be no slash between the host name and the path. It also allows redirects to work where the application is deployed to a subdirectory of a website. Fixes #7977
* test case to lock down the behavior of #7842Yves Senn2012-11-041-0/+5
|
* Use internal instance variable naming scheme for mounted URL helper proxiesSam Pohlenz2012-09-091-0/+11
|
* Fix handling SCRIPT_NAME from within mounted engine'sPiotr Sarnacki2012-08-111-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you mount your application at a path, for example /myapp, server should set SCRIPT_NAME to /myapp. With such information, rails application knows that it's mounted at /myapp path and it should generate routes relative to that path. Before this patch, rails handled SCRIPT_NAME correctly only for regular apps, but it failed to do it for mounted engines. The solution was to hardcode default_url_options[:script_name], which is not the best answer - it will work only when application is mounted at a fixed path. This patch fixes the situation by respecting original value of SCRIPT_NAME when generating application's routes from engine and the other way round - when you generate engine's routes from application. This is done by using one of 2 pieces of information in env - current SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because we have 2 cases to handle: - generating engine's route from application: in this situation SCRIPT_NAME is basically SCRIPT_NAME set by the server and it indicates the place where application is mounted, so we can just pass it as :original_script_name in url_options. :original_script_name is used because if we use :script_name, router will ignore generating prefix for engine - generating application's route from engine: in this situation we already lost information about the SCRIPT_NAME that server used. For example if application is mounted at /myapp and engine is mounted at /blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that we need to keep reference to /myapp SCRIPT_NAME by binding it to the current router. Later on we can extract it and use when generating url Please note that starting from now you *should not* use default_url_options[:script_name] explicitly if your server already passes correct SCRIPT_NAME to rack env. (closes #6933)
* Remove default match without specified methodJose and Yehuda2012-04-241-13/+13
| | | | | | | | | | | | | | | | In the current router DSL, using the +match+ DSL method will match all verbs for the path to the specified endpoint. In the vast majority of cases, people are currently using +match+ when they actually mean +get+. This introduces security implications. This commit disallows calling +match+ without an HTTP verb constraint by default. To explicitly match all verbs, this commit also adds a :via => :all option to +match+. Closes #5964
* Override respond_to? since we are also overriding method_missing.José Valim2012-01-031-0/+7
|
* Make polymorphic_url calls go through application helpers again.thedarkone2011-07-251-0/+12
| | | | This brings back the ability to overwrite/extend url generating methods in application heleprs.
* Fix tests, main_app mounted helper must be defined explicitly now.Piotr Sarnacki2011-04-251-0/+1
|
* Allow mounting engines at '/'Piotr Sarnacki2010-09-301-16/+77
| | | | | Without that commit script_name always become '/', which results in paths like //posts/1 instead of /posts/1
* Change app to main_app in mounted_helpersPiotr Sarnacki2010-09-081-3/+3
|
* Do not require passing :app to mounted helpers, it's actually useless and ↵Piotr Sarnacki2010-09-081-1/+1
| | | | not DRY
* Ensure that url_helpers included after application's ones have higher priorityPiotr Sarnacki2010-09-031-0/+15
|
* Add mounted_helpers to routesPiotr Sarnacki2010-09-031-14/+70
| | | | | | | | | | | | | | | | mounted_helpers are a bit similar to url_helpers. They're automatically included in controllers for Rails.application and each of mounted Engines. Mounted helper allows to call url_for and named helpers for given application. Given Blog::Engine mounted as blog_engine, there are 2 helpers defined: app and blog_engine. You can call routes for app and engine using those helpers: app.root_url app.url_for(:controller => "foo") blog_engine.posts_path blog_engine.url_for(@post)
* Routes refactoring:Piotr Sarnacki2010-09-031-46/+71
| | | | | | | * added more tests for prefix generation * fixed bug with generating host for both prefix and url * refactored url_for method * organized tests for prefix generation
* Use new url_for API instead of including routes.url_helpersPiotr Sarnacki2010-09-031-3/+2
|
* Added some more tests for url generation between Engine and ApplicationPiotr Sarnacki2010-09-031-10/+28
|
* Refactored tests for prefix generation and added test for url generation in ↵Piotr Sarnacki2010-09-031-11/+32
| | | | regular class with default_url_options[:script_name] set
* New way of generating urls for Application from Engine.Piotr Sarnacki2010-09-031-0/+1
| | | | | | | | | It's based specifying application's script_name with: Rails.application.default_url_options = {:script_name => "/foo"} default_url_options method is delegated to routes. If router used to generate url differs from the router passed via env it always overwrites :script_name with this value.
* Allow to generate Application routes inside EnginePiotr Sarnacki2010-09-031-3/+22
| | | | | | This requires knowledge about original SCRIPT_NAME and the parent router. It should be pass through the env as ORIGIAL_SCRIPT_NAME and action_dispatch.parent_routes
* Use env['action_dispatch.routes'] to determine if we should generate prefix ↵Piotr Sarnacki2010-09-031-0/+102
or not. This technique is here to allow using routes from Engine in Application and vice versa. When using Engine routes inside Application it should generate prefix based on mount point. When using Engine routes inside Engine it should use env['SCRIPT_NAME']. In any other case it should generate prefix as env should not be even available.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 10:03:01 +0000