Forms. Specifically entering data, submitting, discovering validation
error, redisplaying the form with user’s entered data and error
messages.
I know how I would approach it left to my own devices (described
below), but wondering if there’s an idiomatic Rails way.
The classic “How To” stuff shows setting values of form elements
directly from models. Well, that’s spiffy if nothing goes wrong, but
in the above sequence of events, that approach doesn’t work.
Normally, in the controller I would load the model with data, I would
then create a form data object (“FDO”) with a placeholder for each
field that applies to the user-entered data in the form. I would
populate the HTML input values with the contents of this FDO. So,
value="<%= fdo.firstName %>" not value="<%= model.firstName %>"
To populate the FDO I test params to see if the form had already been
submitted. If yes, I populate the FDO by copying values from params.
If not, I populate the FDO by copying original data from the model.
This way the form sees virgin data from the database/model when the
form is first displayed, and then the tainted data from user input if
the form is redisplayed.
Does Rails have anything built in for this process, or is the
developer left to implement his own system like I describe above
(which of course is fine with me).
What are your concerns displaying properties from the model?
I have the redisplay of the edit form working fine, but if there’s a
validation error, the form is showing the original data coming from
the database, and not the data that was just entered into the form.
So, in a field for numbers let’s say the form originally displays a
value of 3 (which came from the db). The user edits it and writes
“two” – right now when the validation fails, and we cycle back to
the edit form, it is redisplaying 3 and not “two”. We don’t want the
user to have to edit the form all over again, so we want data from
the params values has to populate the HTML value attributes.
Something has to be in charge of using the database data the first
time, but use the params data the second time around. The form is an
interim container until we approve everything, and then the model
gets updated.
Hmm. I’ve always validated before updating the model. Philosophically
it seems undesireable to stuff the model with data that has not been
vetted.
In a simplistic model that’s just a quick exchange of data with a one
page turn-around, I suppose it doesn’t really matter so long as the
save is prevented.
I guess if that’s the accepted way, I’ll give that a shot.
– gw
On Nov 18, 2007, at 8:01 AM, Nicholas H. wrote:
render :action => 'edit'
if this is not working for you perhaps you could post some code from
validation error, the form is showing the original data coming from
time, but use the params data the second time around. The form is an
def update
displaying properties from the model?
The classic “How To” stuff shows setting values of form elements
Does Rails have anything built in for this process, or is the
developer left to implement his own system like I describe above
(which of course is fine with me).
def update @post = Post.find(params[:id) @post.attributes = params[:post]
if @post.save
redirect_to post_path(@post)
else
render :action => ‘edit’
end
Anyway, following something this will mean that the action (or view)
will be rendered (if the model cannot be saved), displaying the data
that the user entered, because the view will be feeding off the
instance variable for the model with the attributes passed from user
input (not the original values of the model), e.g.:
value = “<%= @post.title %>”
if this is not working for you perhaps you could post some code from
your controller.
Yes, it’s the Rails way to assign to the attributes and save/validate
the model. If the model is not valid then it will not save. The save
method calls #valid? to see if it has been saved or not - you can call
this method as well - e.g. @post.valid?.
Here is a typical method in a