I'm trying to create a form/view that displays a mix of records that
exist in the database and records that the user is working on but that
don't yet exist in the database. I want to leverage all of rails' nice
form helpers, especially the params hash that it generates for the
records when the form is submitted. So - I am creating 'dummy' records
with fake ids to represent the new records that don't really exist in
I'm getting wrapped around the axle when I try and submit the form. I
need to identify the pre-existing records and just save them back to
the database with any modified data. For the new records, I need to
create them fresh and then save them to the database.
I've been trying all sorts of clever tricks to identify the new
records based on their fake ids, but I keep running into difficulties.
I'm wondering if there is a simple convention for handling this
scenario that I am missing, or if this is just one of those scenarios
that requires a lot of work to make it work properly.
Any guidance would be appreciated.
I should add that I feel that I have a reasonable mechanism for
identifying 'old' record ids vs. 'new' record ids. It works great
except for when the user uses the back button and resubmits the form.
So - perhaps what I really need is a mechanism for avoiding double-
Do your "fake" IDs all begin with something like 'new_'?
Rob Biedenharn http://agileconsultingllc.com
they did in my first implementation, but - i ended up changing it as
follows: when i first present the form, i find the highest id of the
preexisting record, i store that in '@last_existing_id'. then render
the view. on submit, i always pass last_existing_id back to the server
as one of the parameters.
So if two different browsers create records at the same time...
this works, except for when the user hits the back button, after
saving, and then saves again. since the back button doesn't re-render,
it doesn't update the '@last_existing_id' in the view and submits the
old and now invalid one.
i think that i went to this new implementation because prepending
'new_' required a little bit of special handling. I also seem to
remember that raisl didn't generate the params hash for the new
records (but i could be mistaken on this).
of course it needs a little special handling, the new records are special! (Or at least different.) You just branch on params[:id] =~ /^new/ (or even params[:id].to_i == 0) and create a new record with the params or find the existing one and update its attributes.
Bu that still doesn't solve the double submit problem:
If the user saves, then clicks the back button, then saves again
the records in the form that had ids of the form 'new_' will still
have ids of the form 'new_'
and redundant copies will be saved to the database.
I worked my way around this particular problem quite trvially:
I pass Time.now to the view. When the view is submitted to the save
method in the controller, it
passes the time stamp back. The controller checks to see if it has
this time stamp in the
session. If not, it stores it. If it does, it fails and issues a
'double submit' warning.
I realize that the problem i was really struggling with is the double
On a related note - yes - good point about the two different browsers
problem. I should use
the 'new_' version.
Thanks for your help.