1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/actionpack/test/fixtures/respond_to
Godfrey Chan 73b1efc58f Lock down new ImplicitRender behavior for 5.0 RC
1. Conceptually revert #20276

   The feature was implemented for the `responders` gem. In the end,
   they did not need that feature, and have found a better fix (see
   plataformatec/responders#131).

   `ImplicitRender` is the place where Rails specifies our default
   policies for the case where the user did not explicitly tell us
   what to render, essentially describing a set of heuristics. If
   the gem (or the user) knows exactly what they want, they could
   just perform the correct `render` to avoid falling through to
   here, as `responders` did (the user called `respond_with`).

   Reverting the patch allows us to avoid exploding the complexity
   and defining “the fallback for a fallback” policies.

2. `respond_to` and templates are considered exhaustive enumerations

   If the user specified a list of formats/variants in a `respond_to`
   block, anything that is not explicitly included should result
   in an `UnknownFormat` error (which is then caught upstream to
   mean “406 Not Acceptable” by default). This is already how it
   works before this commit.

   Same goes for templates – if the user defined a set of templates
   (usually in the file system), that set is now considered exhaustive,
   which means that “missing” templates are considered `UnknownFormat`
   errors (406).

3. To keep API endpoints simple, the implicit render behavior for
   actions with no templates defined at all (regardless of formats,
   locales, variants, etc) are defaulted to “204 No Content”. This
   is a strictly narrower version of the feature landed in #19036 and
   #19377.

4. To avoid confusion when interacting in the browser, these actions
   will raise an `UnknownFormat` error for “interactive” requests
   instead. (The precise definition of “interactive” requests might
   change – the spirit here is to give helpful messages and avoid
   confusions.)

Closes #20666, #23062, #23077, #23564

[Godfrey Chan, Jon Moss, Kasper Timm Hansen, Mike Clark, Matthew Draper]
2016-02-25 01:19:49 -08:00
..
layouts
all_types_with_layout.html.erb
custom_constant_handling_without_block.mobile.erb
iphone_with_html_response_type.html.erb
iphone_with_html_response_type.iphone.erb
using_defaults.html.erb
using_defaults.xml.builder
using_defaults_with_all.html.erb fix respond_to without blocks not working if one of the blocks is all 2013-02-24 11:47:20 -05:00
using_defaults_with_type_list.html.erb
using_defaults_with_type_list.xml.builder
variant_any_implicit_render.html+phablet.erb Add any/all support for variants 2013-12-26 20:36:17 +01:00
variant_any_implicit_render.html+tablet.erb Add any/all support for variants 2013-12-26 20:36:17 +01:00
variant_inline_syntax_without_block.html+phone.erb Inline variants syntax 2013-12-10 11:55:43 +01:00
variant_plus_none_for_format.html.erb Variants can be declared without a block to signify their presence in the controller 2013-12-07 16:32:38 -08:00
variant_with_implicit_template_rendering.html+mobile.erb Lock down new ImplicitRender behavior for 5.0 RC 2016-02-25 01:19:49 -08:00