Fred, thanks. Your explanation led me right to the problem: I had a variable that I wanted to associate with the model object, but just for the life of this form. In a sense it's a 'virtual' attribute because I have no column in the database for it. So - I couldn't use f.text_field for it. Instead, I tried to force rails to package it up in a nice params hash by manually writing out the html for this attribute in the following manner: "blah blah id="vehicle_record_miles_driven" name="vehicle_record[miles_driven]". When I passed the view an object with an existing id, this worked fine. Otherwise - it caused the conflict. So - now that I know the root of the conflict, next question: what is the conventional way to handle such 'virtual' attributes? Would it be to simply create a read and write accessor for it?
Second question related to forms: When I use fields_for 'vehicle_record[]' (and I remove the offending html), rails produces a params hash that: In the case of a new object with no id: has a key: 'vehicle_record' with a corresponding value that is an array of hashes of the attributes. In the case of an existing object that has an id: has a key: 'vehicle_record' with a corresponding value that is itself a hash with a key equal to the id of the object and a value that is the attributes of the object. So - what's the conventional manner for handling this in the controller? I could just query to see if params ['vehicle_record'].class == Array vs. hash and then decide based on that whether to parse it as a new object or an existing one, but that seems a little inelegant. On the other hand, I could use 'form_for' which generates the same params hash format for both cases (existing and new object) but does not include an id. In this case, I would have the controller pass the view an instance variable: @record_id = 'foo' (in the case of an existing object or @record_id = nil (in the case of a new one. Then i'd pass it back as a hidden field and i'd use a nil value to indicate that it's a new object. This seems similar to your suggestion to use the 'index' option. So, basically - i'm asking what the conventional manner for doing this is... In the abstract, the problem is creating a controller and form that can handle either a new object or an existing one while fully leveraging all the goodness that rails provides. After a bunch of reading on this, i've yet to find a 'convention' for this. Thanks always for your generous support! Yoram On Feb 18, 12:17 am, Frederick Cheung <frederick.che...@gmail.com> wrote: > On Feb 18, 5:38 am, "yber...@msn.com" <yber...@msn.com> wrote: > > > When my controller passes the view an existing object, I submit the > > form and everything's dandy. When my controller passes the view a new > > object that does not have an id, then I get the error message > > regarding conflicting container types. > > > Why? Can I use the same form to handle both new and edited objects and > > Well it's a little tricky to say without seeing the html but that > error message usually means that in the same form you have something > like > foo[]=bar and foo[bar]=baz > > it may be that passing an :index option to fields for when dealing > with a new record is the way out > > Fred > > > at the same time to work as expected with f.text_field? Am I going > > about it the wrong way? I spent quite a bit of time reading the > > tutorials on the web but still don't understand what's going on here. > > > Any guidance 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
