No response_to block in edit action (generated using scaffold)?

Does anyone know why there is no respond_to for generated edit actions? Every other action in typical forest controllers has a respond_to to output html and xml formats. Why is the edit action an exception?

I am using the latest version of Ruby on Rails (2.1.1).

+7
ruby ruby-on-rails
source share
3 answers

Rails handles the 99% case: it is unlikely that you will ever need to do any XML or JSON translations in your Edit action, because not visually the Edit action is very similar to the Show action. Non-visual clients who want to update the model in their application can invoke the controller this way.

 GET /my_models/[:id].xml (Show) 

Then the client application can make any transformations or changes and publish (or put) the results in

 PUT /my_models/[:id].xml (Update) 

When you call this, you usually do this to get an editable form of the Show action:

 GET /my_models/[:id]/edit 

And it is intended for human use. 99% of the time, that is. Since this is unusual for transforming data into an β€œEdit” action, Rails assumes that you do not, and SUBMITS your code, leaving response_to on the scaffold.

+12
source share

In part. Some might wonder why rails scaffolding still has a response_to block for a new action; whereas the editing action does not work. This is because the request for something like:

 GET /my_models/new.xml 

... returns an XML template that can be used to create a new model.

+2
source share

Since the edit action will only be called from HTML, there is no need for the edit form to return in the XML context. Using REST, you simply do put put directly to update with the relevant information.

+1
source share

All Articles