Many named routes have keys that are required to successfully resolve. If a key is left off like this:
<%= link_to 'user', user_path %>
This will produce an error like this:
No route matches {:action=>"show", :controller=>"users"}
Since we know that the :id is missing, we can add extra debugging information to the error message.
No route matches {:action=>"show", :controller=>"users"} missing required keys: [:id]
This will help new and seasoned developers look closer at their parameters. I've also subclassed the routing error to be clear that this error is a result of attempting to generate a url and not because the user is trying to visit a bad url.
While this may sound trivial this error message is misleading and confuses most developers. The important part isn't what's in the options its's what's missing. Adding this information to the error message will make debugging much more obvious.
This is the sister pull request of https://github.com/rails/journey/pull/44 which will be required to get they missing keys into the correct error message.
Example Development Error in Rails: http://cl.ly/image/3S0T0n1T3421
Methods provided by RecordIdentifier are not widely used in controllers
nowadays as they're view specific (this is probably a legacy left after
RJS rendering directly in controllers). However if people still need to
use it, it's trivial to include ActionView::RecordIdentifier by
themselves.
ActionDispatch::Routing::UrlFor was always required in UrlHelpers. This
was changed by splitting previous implementation of UrlHelper into 2
modules: ActionView::Helpers::UrlHelper and
ActionView::Routing::UrlHelper. The former one keeps only basic
implementation of url_for. The latter adds features that allow to use
routes and is only required when url_helpers or mounted_helpers are
required.
default_formats array is used by LookupContext in order to allow
rendering templates when :formats option is not passed. Previously it
was always set to Mime::SET, which created dependency on Action Pack. In
order to remove this dependency, Mime::SET is used only if
ActionController is loaded.
We can use another way to instantiate ActionView::Base, by passing
renderer as a first option. Thanks to that we can just pass prefixes to
LookupContext instead stubbing them on the controller. This is also good,
because that kind of API is used in Rails code.
This is another step in moving Action View's dependencies in Action Pack
to Action View itself. Also, HtmlScanner seems to be better suited for
views rather than controllers.
Since it's more about DOM classes and ids it belongs to Action View
better. What's more, it's more convenient to make it part of Action View
to follow the rule that Action Pack can depend on Action View, but not
the other way round.
we should take disabled option not only from `html_options` hash but from
`options` hash too like `build_select` method does it. So
datetime_select("post", "updated_at", { :discard_minute => true }, { :disabled => true })
datetime_select("post", "updated_at", :discard_minute => true , :disabled => true)
both these variants work now
closes#7431
Fix indentation on template errors to consider line number character count.
For instance, when an error is shown, if the related source code snippet has line numbers from, lets say, 8-12, the lines are left aligned, which means the code indent is wrong:
8: foo
9: bar
10: raise
11: baz
12: ...
This changes it to right align the source code snippet, so that the indentation is correct:
8: foo
9: bar
10: raise
11: baz
12: ...
Further simplify the option_html_attributes method after the changes
introduced in dacbcbe55745aa9e5484b10b11f65ccca7db1c54 to not escape the
html options here (since they're going to be escaped down the chain in
content tag).
if nil or an empty array is passed into form_for you get a horrible error message, this one is much more indicative of what the programmer needs to know to fix the problem.
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)
