# Fields\_for and Conflicting types for parameter containers. Expected an instance of Hash but found a **URL:** \ **Category:** Rails\ **Created:** [February 18, 2009, 6:39am UTC](https://www.ruby-forum.com/t/fields-for-and-conflicting-types-for-parameter-containers-expected-an-instance-of-hash-but-found-a/160619 "2009-02-18T06:39:48Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [February 18, 2009, 6:39am UTC](https://www.ruby-forum.com/t/fields-for-and-conflicting-types-for-parameter-containers-expected-an-instance-of-hash-but-found-a/160619/1 "2009-02-18T06:39:48Z")
I’m trying to use ‘fields\_for’ in a form. I want the same form to support both the creation of new obejcts as well as the editing of old ones. So - in my controller, sometimes I will pass to the form an object that already exists in my database and has an id and other times I will pass it a newly created instance of an object that does not yet exist in the database and does not have an id. I want the params hash to have the id of the object if its available, so - i’m using fields\_for ‘vehicle\_record[]’, as opposed to fields for ‘vehicle\_record’. Also, when I am using the form to render an existing object, i’d like it to automatically display the values of the existing parameters wherever I use f.text\_field. And - i’d like it to package up those params that exist into a nice params hash. 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 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 ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [February 18, 2009, 9:18am UTC](https://www.ruby-forum.com/t/fields-for-and-conflicting-types-for-parameter-containers-expected-an-instance-of-hash-but-found-a/160619/2 "2009-02-18T09:18:04Z")
On Feb 18, 5:38 am, “removed\_email\_address@domain.invalid” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [February 18, 2009, 2:30pm UTC](https://www.ruby-forum.com/t/fields-for-and-conflicting-types-for-parameter-containers-expected-an-instance-of-hash-but-found-a/160619/3 "2009-02-18T14:30:25Z")
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 C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [February 18, 2009, 3:09pm UTC](https://www.ruby-forum.com/t/fields-for-and-conflicting-types-for-parameter-containers-expected-an-instance-of-hash-but-found-a/160619/4 "2009-02-18T15:09:59Z")
Yes but somehow I thought that what i’m trying to do here is pretty simple and that it would not require complex form stuff. Maybe I should study the complex form stuff more closely. Thanks for the pointer. On Feb 18, 5:43 am, Frederick C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [February 18, 2009, 3:16pm UTC](https://www.ruby-forum.com/t/fields-for-and-conflicting-types-for-parameter-containers-expected-an-instance-of-hash-but-found-a/160619/5 "2009-02-18T15:16:27Z")
On 18 Feb 2009, at 13:29, removed\_email\_address@domain.invalid wrote: > 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? Yes, with accessors you should just be able to use f.text\_field etc… > a key equal to the id of the object and a value that is the attributes > of the object. by passing an index option you can force what fields\_for uses (by default it’s the record’s id and blank if the record is unsaved. THere are various ways you can generated what identifiers you autogenerate for new records, that’s one of the things I think the complex forms stuff covers. Fred ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [February 18, 2009, 2:44pm UTC](https://www.ruby-forum.com/t/fields-for-and-conflicting-types-for-parameter-containers-expected-an-instance-of-hash-but-found-a/160619/6 "2009-02-18T14:44:37Z")
On 18 Feb 2009, at 13:29, removed\_email\_address@domain.invalid wrote: > 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. Have you looked at the new complex forms stuff ? Fred