This project is archived and is in readonly mode.
Make #respond_to implicit in controller actions
Reported by Zach Dennis | September 30th, 2008 @ 04:04 PM | in 3.0.2
Currently when using different formats in a controller you have to be explicit with the respond_to.
ie:
def some_action
respond_to do |format|
format.html { do this }
format.xml { do this }
format.json { do this }
end
end
It seems that you should be able to just use format and have that automatically handle the responder. For example:
def some_action
format.html { do this }
format.xml { do this }
format.json { do this }
end
Attached is a simple patch by Brandon Keepers and myself to make this so. One limitation is that this won't work in before filters. We realize this may be desired, but feel it can be a separate patch and shouldn't affect the inclusion of this functionality for a controller action.
Comments and changes to this ticket
-
Zach Dennis September 30th, 2008 @ 04:31 PM
Additional reasons for this patch:
- respond_to by itself gives no value besides supplying us with a format object
- respond_to requires that an unnecessary level of nesting
- respond_to is an abstraction that can be abstracted away
-
Mark Van Holstyn October 1st, 2008 @ 01:09 AM
+1
I think this is a great patch, removing code that provides no value and just adds noise. I don't see any downsides.
-
Daniel Parker October 1st, 2008 @ 05:47 PM
I would recommend changing the naming, instead to say:
def some_action respond_to.html { render ... } respond_to.json { render_json ... } respond_to.xml { render_xml ... } end
You could easily implement this functionality by simply having respond_to return the format object if you don't pass it a block directly:
def respond_to if block_given? # ... original respond_to ... else # ... just return the format object since we'll next be calling .html, .json, etc. end end
-
josh January 2nd, 2009 @ 04:02 AM
- Milestone cleared.
- State changed from new to open
- Assigned user set to DHH
-
Amos King January 2nd, 2009 @ 09:16 PM
This is great. I would add a dep warning to the old way and remove the old block way on the next release from there. That way we can get rid of the block check and some lines of code.
+1
-
Zach Dennis January 13th, 2009 @ 02:16 AM
I updated the original patch with Daniel's suggestion of just making respond_to without a block, instead of introducing a new method "format" to the controller.
I like Amos' suggestion for deprecating using a block, but this is not included in this patch. It would be easy enough to add if the core team felt comfortable doing that.
The idea would be that:
respond_to do |format| format.html { # this becomes deprecated } end
and
respond_to.html { # this becomes the new default }
-
Pratik March 13th, 2009 @ 03:49 PM
- State changed from open to hold
- Assigned user changed from DHH to Yehuda Katz (wycats)
-
Jean May 27th, 2010 @ 10:34 PM
Looks like the old behaviour is still around and the new doesn't work in rails3 beta3. Is this going to make it to rails3 or should it be reassigned to a future release ?
-
a4490302sc July 21st, 2010 @ 08:16 AM
- Importance changed from to High
heether an cheap JC12 replica onluine shopping blog is Replica Richard Mille Watches relialbe or not, the buy replica Corum watch shopper shoould sans pareil W1540956 replica sale concede the stable address rolex replica watches sale prvided on the void. cheap 4541.50.00 replica A precise motion consign Replica Watches always certify an addess L2.655.4.71.6 replica that is reachable. integrity omega replica Watch sale the company bequeath again cheap 8605 replica watches lock up a conytact number because its customers. Vintage Diam
-
Dmitry Sokurenko July 28th, 2010 @ 10:10 AM
respond_to block is a really unnecessary abstraction. +1
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>