Bu that still doesn't solve the double submit problem: If the user saves, then clicks the back button, then saves again (without refreshing), 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 submit problem. On a related note - yes - good point about the two different browsers problem. I should use the 'new_' version. Thanks for your help. Y On Feb 9, 7:16 am, Rob Biedenharn <[email protected]> wrote: > On Feb 9, 2009, at 9:58 AM, [email protected] wrote: > > > 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). > > > y > > 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. > > -Rob > > > > > On Feb 9, 6:51 am, Rob Biedenharn <[email protected]> wrote: > >> On Feb 9, 2009, at 9:43 AM, [email protected] wrote: > > >>> 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- > >>> submits. > > >>> On Feb 9, 6:36 am, "[email protected]" <[email protected]> wrote: > >>>> 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 > >>>> the database. > > >>>> 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. > > >>>> Yoram > > >> Do your "fake" IDs all begin with something like 'new_'? > > >> -Rob > > >> Rob Biedenharn http://agileconsultingllc.com > >> [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
