Rails - Aug 2009 - Passing Parameters to a Re-Rendered View

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 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?
-- 
Posted via http://www.ruby-forum.com/.

> 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

Doug Jolley 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
-- 
Posted via http://www.ruby-forum.com/.

2009/8/22 djolley
<ddjolley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
>> 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.
>
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

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

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

Thanks a batch.

          ... doug

2009/8/23 djolley
<ddjolley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> 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

> 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

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

On Sun, 2009-08-23 at 10:53 -0700, djolley wrote:
> > 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
> >

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! :) )  However, there is no doubt
about it, the flash hash is an invaluable tool for passing values
around.  Thanks for mentioning it.

          ... doug