I have a strange bug that''s driving me slightly crazy. Maybe the symptoms will be more meaningful to someone else here... I have a set of REST actions in my controller and a form_for in both my new and edit views, in both cases with fields_for constructs embedded. The models have some validation rules in place. A successful create action renders the edit view to allow modifications to be made the data. However, if I enter invalid data into some of the embedded fields in the form, when I resubmit the form the second time, with either valid or invalid data, the browser ends up (apparently) invoking the index action and it associated view instead of create. On the face of it it kind of looks as if the browser request is coming in as a GET (since that would turn a create index into an index), but there''s no obvious reason that that should happen for a form, nor any inking in firebug that that''s what''s actually happening. Does this ring any bells with anyone? No doubt something simple, but my sleep deprived brain just isn''t seeing it right now. Thanks for any advice. Mark. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Ok, so this didn''t attract any suggestions, but here fwiw is how I solved the problem... I still don''t know exactly why I was ending up in the index view, but it seems that the underlying problem was that when the form was being resubmitted after validation failure, Rails was interpreting my form_for as an "edit" form, rather than a "new" form - and consequently putting a hidden _method = put parameter in the form markup. Apparently the reason it was treating this as an "edit" form the second time around is that the validation failure was happening in the "create" action on the embedded "fields_for" fields, but this only happened after the primary fields for the "form_for" had already been save! ''d. I had the whole thing wrapped in a transaction, which was correctly preventing the primary fields from actually making it to the db, but the objects themselves were still being treated as if they had been saved - even though they hadn''t - and so Rails apparently figured that the purpose of the subsequent form was to edit this "existing" data. The solution: in my "create" action, I just moved the save! of the primary "form_for" fields to occur _after_ those embedded in "fields_for" have been save! ''d. This means that if the primary fields only ever get created if the embedded fields have successfully validated, i.e. the transaction as a whole is good. MT On Jul 18, 4:04 pm, MarkMT <mark.thom...-EkmVulN54Sk@public.gmane.org> wrote:> I have a strange bug that''s driving me slightly crazy. Maybe the > symptoms will be more meaningful to someone else here... > > I have a set of REST actions in my controller and a form_for in both > my new and edit views, in both cases with fields_for constructs > embedded. The models have some validation rules in place. > > A successful create action renders the edit view to allow > modifications to be made the data. > > However, if I enter invalid data into some of the embedded fields in > the form, when I resubmit the form the second time, with either valid > or invalid data, the browser ends up (apparently) invoking the index > action and it associated view instead of create. On the face of it it > kind of looks as if the browser request is coming in as a GET (since > that would turn a create index into an index), but there''s no obvious > reason that that should happen for a form, nor any inking in firebug > that that''s what''s actually happening. > > Does this ring any bells with anyone? No doubt something simple, but > my sleep deprived brain just isn''t seeing it right now. > > Thanks for any advice. > > Mark.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi -- On Sat, 19 Jul 2008, MarkMT wrote:> > Ok, so this didn''t attract any suggestions, but here fwiw is how I > solved the problem... > > I still don''t know exactly why I was ending up in the index view, but > it seems that the underlying problem was that when the form was being > resubmitted after validation failure, Rails was interpreting my > form_for as an "edit" form, rather than a "new" form - and > consequently putting a hidden _method = put parameter in the form > markup. > > Apparently the reason it was treating this as an "edit" form the > second time around is that the validation failure was happening in the > "create" action on the embedded "fields_for" fields, but this only > happened after the primary fields for the "form_for" had already been > save! ''d. I had the whole thing wrapped in a transaction, which was > correctly preventing the primary fields from actually making it to the > db, but the objects themselves were still being treated as if they had > been saved - even though they hadn''t - and so Rails apparently figured > that the purpose of the subsequent form was to edit this "existing" > data. > > The solution: in my "create" action, I just moved the save! of the > primary "form_for" fields to occur _after_ those embedded in > "fields_for" have been save! ''d. This means that if the primary fields > only ever get created if the embedded fields have successfully > validated, i.e. the transaction as a whole is good.You might look into the build method, which lets you create an association in memory without saving, and then, assuming the validations are in place, it will do an all-or-nothing save. That may be a good defense against the (in my view) excessive "magic" of form_for(@object) :-) David -- Rails training from David A. Black and Ruby Power and Light: Intro to Ruby on Rails July 21-24 Edison, NJ Advancing With Rails August 18-21 Edison, NJ See http://www.rubypal.com for details and updates! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks David. I''ll take a look at that. Mark. On Jul 20, 6:42 am, "David A. Black" <dbl...-0o/XNnkTkwhBDgjK7y7TUQ@public.gmane.org> wrote:> Hi -- > > > > On Sat, 19 Jul 2008,MarkMTwrote: > > > Ok, so this didn''t attract any suggestions, but here fwiw is how I > > solved the problem... > > > I still don''t know exactly why I was ending up in the index view, but > > it seems that the underlying problem was that when the form was being > > resubmitted after validation failure, Rails was interpreting my > > form_for as an "edit" form, rather than a "new" form - and > > consequently putting a hidden _method = put parameter in the form > > markup. > > > Apparently the reason it was treating this as an "edit" form the > > second time around is that the validation failure was happening in the > > "create" action on the embedded "fields_for" fields, but this only > > happened after the primary fields for the "form_for" had already been > > save! ''d. I had the whole thing wrapped in a transaction, which was > > correctly preventing the primary fields from actually making it to the > > db, but the objects themselves were still being treated as if they had > > been saved - even though they hadn''t - and so Rails apparently figured > > that the purpose of the subsequent form was to edit this "existing" > > data. > > > The solution: in my "create" action, I just moved the save! of the > > primary "form_for" fields to occur _after_ those embedded in > > "fields_for" have been save! ''d. This means that if the primary fields > > only ever get created if the embedded fields have successfully > > validated, i.e. the transaction as a whole is good. > > You might look into the build method, which lets you create an > association in memory without saving, and then, assuming the > validations are in place, it will do an all-or-nothing save. That may > be a good defense against the (in my view) excessive "magic" of > form_for(@object) :-) > > David > > -- > Rails training from David A. Black and Ruby Power and Light: > Intro to Ruby on Rails July 21-24 Edison, NJ > Advancing With Rails August 18-21 Edison, NJ > Seehttp://www.rubypal.comfor details and updates!--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---