| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
The request.script_name is dup-d which allocates an extra string. It is most commonly an empty string "". We can save a ton of string allocations by checking first if the string is empty, if so we can use a frozen empty string instead of duplicating an empty string.
This change buys us 35,714 bytes of memory and 893 fewer objects per request.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- The request needs to be instance of ActionDispatch::Request or an
object that responds to host, optional_port, protocol and
symbolized_path_parameter.
- This documentation was correctly added in
https://github.com/rails/rails/commit/e3b3f416b57f5642ea25078485f7e9394ad04526
but was changed to
https://github.com/rails/rails/commit/e1ceae576e3911f3e6708b5d19a0e3ef63769eb7.
- Fixes #16160.
|
|
|
|
|
| |
encapsulate env in the request so that we can eventually move away from
the env hash
|
|
|
|
| |
this will help decouple us from using the rack env hash
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A regression was introduced in 5b3bb6, generating route from within an
engine to an another engine resulted in prefixing a path with the
SCRIPT_NAME value.
The regression was caused by the fact that SCRIPT_NAME should be
appended only if it's the SCRIPT_NAME for the application, not if it's
SCRIPT_NAME from the current engine.
closes #10409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|