Rails - Feb 2009 - forms that mix new and old records

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
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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, "yber...-uAjRD0nVeow@public.gmane.org"
<yber...-uAjRD0nVeow@public.gmane.org> 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
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Feb 9, 2009, at 9:43 AM, ybernet-uAjRD0nVeow@public.gmane.org
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, "yber...-uAjRD0nVeow@public.gmane.org"
<yber...-uAjRD0nVeow@public.gmane.org> 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
Rob-xa9cJyRlE0mWcWVYNo9pwxS2lgjeYSpx@public.gmane.org


--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Feb 9, 2009, at 9:58 AM, ybernet-uAjRD0nVeow@public.gmane.org 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
<R...-xa9cJyRlE0mWcWVYNo9pwxS2lgjeYSpx@public.gmane.org> wrote:
>> On Feb 9, 2009, at 9:43 AM, yber...-uAjRD0nVeow@public.gmane.org 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, "yber...-uAjRD0nVeow@public.gmane.org"
<yber...-uAjRD0nVeow@public.gmane.org> 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
>> R...-xa9cJyRlE0mWcWVYNo9pwxS2lgjeYSpx@public.gmane.org

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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
<R...-GBZH0y1GwQfnZcttdmLDtcI/UQi/AW5J@public.gmane.org>
wrote:
> On Feb 9, 2009, at 9:58 AM, yber...-uAjRD0nVeow@public.gmane.org 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
<R...-xa9cJyRlE0mWcWVYNo9pwxS2lgjeYSpx@public.gmane.org> wrote:
> >> On Feb 9, 2009, at 9:43 AM, yber...-uAjRD0nVeow@public.gmane.org
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,
"yber...-uAjRD0nVeow@public.gmane.org"
<yber...-uAjRD0nVeow@public.gmane.org> 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
> >> R...-xa9cJyRlE0mWcWVYNo9pwxS2lgjeYSpx@public.gmane.org
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---