| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| | |
|
| | |
|
| |
|
|
| |
Removed some useless docstrings and no-doc'ed some.
|
| |
|
|
|
| |
It fails if routes from to railties are called in one context,
for example: blog.posts_path and main_app.users_path
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
allowing for easy manipulation of the host during link generation.
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
There were actually 2 problems with this one:
* script_name was added to options as a string and then it was used
in RouteSet#url_for with usage of <<, which was changing the original
script_name
* the second issue was with _with_routes method. It was called in RoutesProxy
to modify _routes in view_context, but url_helpers in views is just delegating
it to controller, so another _with_routes call is needed there
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit f7ba614c2db improved the internal consistency of the different
means of accessing routes, but it introduced some problems at the level
of code comments and user-visible strings.
This commit applies fixes on three levels:
Firstly, we remove or replace grammatically invalid constructs such as
"a routes" or "a particular routes".
Secondly, we make sure that we always use "the router DSL" or "the
router syntax", because this has always been the official terminology.
Finally, we make sure that we only use "routes" when referring to the
application-specific set of routes that are defined in the
"config/routes.rb" file, we use "router" when referring on a more
abstract level to "the code in Rails used to handle routing", and we use
"routing" when we need an adjective to apply to nouns such as
"url_helpers. Again this is consistent with historical practice and
other places in the documentation.
Note that this is not a sweep over the entire codebase to ensure
consistent usage of language; it is just a revision of the changes
introduced in commit f7ba614c2db.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
a way to specify a default SCRIPT_NAME when generating URLs out of the context of a request.
|
| | |
|
| |
|
|
|
|
| |
{ ... }
This attr_accessor can be set in a before filter or in the action itself.
Overwriting default_url_options still works but will output a deprecation notice.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
and ActionController up to AbstractController.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Move #set_cookie and #delete_cookie inline to optimize. These optimizations should
almost certainly be sent back upstream to Rack. The optimization involves using
an ivar for cookies instead of indexing into the headers each time.
* Was able to use a bare Hash for headers now that cookies have their own joining
semantics (some code assumed that the raw cookies were an Array).
* Cache blankness of body on body=
* Improve expand_cache_key for Arrays of a single element (common in our case)
* Use a simple layout condition check unless conditions are used
* Cache visible actions
* Lazily load the UrlRewriter
* Make etag an ivar that is set on prepare!
|
|
|
their module locations
|
