Passing Parameters to a Re-Rendered View

Rails
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 J. 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

Doug J. wrote:

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

Ok, see if this helps. I assume your Modify form’s is calling update
action

def modify
@member = Member.find(5)
end

def update
if @member.update_attributes(params[:member])
#updated…so something
else
#failed…may be due to validation
render :action => “modify”
end
end

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

2009/8/22 djolley [email protected]:

the relevant record object and assigns it to the @member instance
Thanks for the help.

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

8

2009/8/23 djolley [email protected]:

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

Thanks a batch.

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

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

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
11

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