Passing Parameters to a Re-Rendered View

rubyonrails-talk
1

Please consider a CRUD action and view for modifying a record. The form for making the modification is called by the URL, "http:// www.mydomain.com/members/modify/5". This calls the "modify" action of the "members" controller and passes the :id parm of "5". The action uses the :id param to retrieve the appropriate record which is passed to the view in the @member instance variable. The view uses the data provided in @member to pre-populate the form with the current values. The user uses the form to make any desired modifications to the current values and submits the form to another action which saves the updated data and redirects the user to another URL.

Under normal circumstances the above works just fine. If, however, the form is validated and there is a validation error; then, the original form needs to be re-rendered with error messages. The problem is that, as far as I can see, 'render' does not allow params to be passed to the view; so, in this second rendering of the form, the form doesn't have any data to pre-populate the fields.

My question is: How do I pass the parameters to the re-rendered view? In fact, now that I think about it, how are parameters normally passed to a rendered view. I would think that it would all be the same process.

Thanks for any input.

          ... doug

2

Doug Jolley wrote:

Please consider a CRUD action and view for modifying a record. The form for making the modification is called by the URL, "http:// www.mydomain.com/members/modify/5". This calls the "modify" action of the "members" controller and passes the :id parm of "5". The action uses the :id param to retrieve the appropriate record which is passed to the view in the @member instance variable. The view uses the data provided in @member to pre-populate the form with the current values. The user uses the form to make any desired modifications to the current values and submits the form to another action which saves the updated data and redirects the user to another URL.

Under normal circumstances the above works just fine. If, however, the form is validated and there is a validation error; then, the original form needs to be re-rendered with error messages. The problem is that, as far as I can see, 'render' does not allow params to be passed to the view; so, in this second rendering of the form, the form doesn't have any data to pre-populate the fields.

My question is: How do I pass the parameters to the re-rendered view? In fact, now that I think about it, how are parameters normally passed to a rendered view. I would think that it would all be the same process.

Thanks for any input.

          ... doug

Doug, if I understand you correctly, your pre-population doesn't seem to hold values when validation fails during an update?.

How do you prepopulate the values?. Using form events?

3

Doug, if I understand you correctly, your pre-population doesn't seem to hold values when validation fails during an update?.

How do you prepopulate the values?

There are two controller actions involved. Initially, the first action is called with a URL like, "http://www.mydomian.com/members/ modify/5". Thus, this action receives the id of the relevant record in the URL (in this case, '5'). This action uses that id to retrieve the relevant record object and assigns it to the @member instance variable. This action then renders the form view which uses the @member instance variable to prepopulate the fields. The user makes any desired changes to the prepopulated form values and then submits the modified form data to the second controller action. The second action creates a new record from the submitted form data; and, absent any validation errors saves it. If there are validation errors, the original form needs to be re-rendered but this time there is no @member instance variable for it to use to prepopulate the fields. That's the problem. Is that more clear?

Thanks for the help.

         ... doug

4

Assuming that the action to update the record (ie the action receiving the form) is called update then normally this would look something like:

  def update     @member = Mamber.find(params[:id])

    respond_to do |format|       if @member.update_attributes(params[:member])         flash[:notice] = 'Member was successfully updated.'         format.html { redirect_to(@member) }         format.xml { head :ok }       else         format.html { render :action => "edit" }         format.xml { render :xml => @member.errors, :status => :unprocessable_entity }       end     end   end

so @member is populated appropriately for the re-display of the edit action

Colin

5

Thanks for the input.

I haven't actually tried it yet; but, I don't think that it's going to work.

I'm not sure that I'm totally onboard with your condition statement:

if @member.update_attributes(params[:member])

but, let's just assume that it works. We're really only interested in the case where the condition isn't satisfied and only the else clause is executed. When that happens the following gets executed:

render :action => "modify"

That's exactly what I was dealing with and the problem is that within update the @member instance variable is not defined so that it can be used by the view in populating the form fields.

Thanks for the suggestion though.

            ... doug

6

Perfect! I get it. I guess it's just a case of getting one's head screwed on correctly.

Thanks a batch.

          ... doug

7

If you use the scaffold generator for generating things in the first place then skeleton methods will be provided for you to do the basic CRUD stuff that you can then adjust to your requirements. For example

script/generate scaffold MyModel name:string title:string content:text

See the RoR getting started guide for more info.

Colin

8

If you use the scaffold generator for generating things in the first place then skeleton methods will be provided for you to do the basic CRUD stuff that you can then adjust to your requirements.

Thanks, Colin. I'm aware of that. In fact, I think that I may actually have started with the scaffold.

You may recall that my original inquiry in this topic was posted in another thread and I botched that post to the point where I needed to start over. Anyway, in that post, I pointed out that I was trying to do some consolidation of similar actions and views. I'm not sure that you thought that was a good idea. In any event, my point is that what I was dealing with may have been a morphed scaffolding.

Whatever, I do appreciate your taking the time to square me away on this issue. Thanks for the help.

          ... doug

9

Hi Doug,

I was doing some reading yesterday and remembered the problem you were having. One thing I didn't mention before, and haven't seen in the thread, that might help you is the flash hash. One of it's intended uses is to allow the 'persistance' of stuff like error messages between redirects. @errors doesn't survive, but if you assign them to the flash hash before you do the redirect, they'll be there for use in that view.

HTH, Bill

10

Hi, Bill --

The flash thing has been mentioned somewhere along the way; but, it was not recommended for this purpose. In fact, the thing is that for this purpose it's not needed if one has their head screwed on correctly. (Obviously I didn't! :slight_smile: ) However, there is no doubt about it, the flash hash is an invaluable tool for passing values around. Thanks for mentioning it.

          ... doug