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.
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.
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
5ea6b0df9a
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
Rails includes a single character body to a head(:no_content) response to work around an old Safari bug where headers were ignored if no body sent.
This patch brings the behavior slightly closer to spec if :no_content/204 is explicity requested via a head only response.
Status comparison done on symbolic and numeric values
Not returning any content when responding with head and limited to a status code that explicitly states no content will be returned - 100..199, 204, 205, 304.
responses.
Processing controller actions in a separate thread allows us to work
around the rack api - we can allow the user to set status and headers,
then block until the first bytes are written. As soon as the first
bytes are written, the main thread can return the status, headers, and
(essentially) a queue for the body.
When someone sends malformed authorization header, like:
Authorization: Token foobar
given token should be just ignored and resource should not be authorized,
instead of raising error. Before this patch controller would return 401 header
only for well formed tokens, like:
Authorization: Token token=foobar
and would return 500 in former case.
Assuming the type ":touch", Collector.new was calling
send(:touch), which instead of triggering method_missing
and generating a new collector method, actually
invoked the private method `touch` inherited from
Object.
By generating the method for each mime type as it
is registered, the private methods on Object can
never be reached by `send`, because the `Collector`
will have them before `send` is called on it.
To do this, a callback mechanism was added to Mime::Type
This allows someone to add a callback for whenever
a new mime type is registered. The callback then
gets called with the new mime as a parameter.
This is then used in AbstractController::Collector
to generate new collector methods after each mime
is registered.
* master:
Add documentation for inheritance_column method
Use ArgumentError vs. RuntimeError, which is more precise.
CSV fixtures aren't supported by default anymore, update generated test_helper.rb to reflect that
fix quoting for ActiveSupport::Duration instances
Add few information on the field types
Add the options method to action_controller testcase.
To test uploading a file without using fixture_file_upload, a posted
ActionDispatch::Http::UploadedFile should not be paramified (just like
Rack::Test::UploadedFile).
(Rack::Test::UploadedFile and ActionDispatch::Http::UploadedFile don't
share the same API, tempfile is not accessible on
Rack::Test::UploadedFile as discussed in
https://github.com/brynary/rack-test/issues/30)
There are several aspects to this commit, that don't well fit into broken down
commits, so they are detailed here:
* When a user uses response.headers['Cache-Control'] = some_value, then the
documented convention in ConditionalGet is not adhered to, in this case,
response.cache_control is ignored due to `return if
self[CACHE_CONTROL].present?`
* When a middleware sets cache-control headers that would clobber, they're
converted to symbols directly, without underscores. This would lead to bugs.
* Items that would live in :extras if set through expires_in, are placed
directly in the @cache_control hash, and not respected in many cases
(somewhat adhering to the aforementioned documentation).
* Although quite useless, any directive named 'extras' would be ignored.
The general convention applied is that expires_* take precedence, but no longer
overwrite everything and expires_* are ALWAYS applied, even if the header is
set.
I am still unhappy about the contents of this commit, and the code in general.
Ideally it should be refactored to no longer use :extras. I'd likely recommend
expanding @cache_control into a class, and giving it the power to handle the
merge in a more efficient fashion. Such a commit would be a larger change that
could have additional semantic changes for other libraries unless they utilize
expires_in in very standard ways.
