141 4 true 2008-10-11T17:31:12+01:00 8406 1202 add-attributes-writer-method-for-an-association 19 8994 committed actionview activerecord enhancement patch 2009-12-03T14:45:27+00:00 22610 Dusan Maliarik Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 This is the same problem :accessible tackled, but with support for creation/updating/destroying associated records. # What's in the patch? # * AutosaveAssociation, which as the name implies automatically saves associations, not only on create as is the default. * NestedParams, which is my take on this problem. It creates/updates/ destroys associations. It uses AutosaveAssociation. * FormBuilder with NestedParams support, which adds code to #fields_for for handling NestedParams enabled models. * A few general patches not necessarily related to this new functionality. Namely: * Added mattr_accessor's for valid_keys_for_has_one_through_association & valid_keys_for_has_and_belongs_to_many_association. http://github.com/alloy/rails/commit/bdb4b34197544c473d369058c4c9609787f35ad0 * Added a association instance get and set method, to dry up the associations code. http://github.com/alloy/rails/commit/e5dff966083030aeca9bb40890b92c04f9018357 http://github.com/alloy/rails/commit/e4822d2a9d0aa047966335187ce78e40bb5488af * Remove MySQL BEGIN and COMMIT queries from $queries_executed before asserting number of queries. http://github.com/alloy/rails/commit/fbcfcec2fd320ff913b83aa619ee94c636199a10 # Examples # _Taken from the docs._ When the <tt>:nested_params</tt> option is enabled an extra attributes writer will be created for the association. The attributes writer allows attributes of the associated model to be set directly with a hash. This is handy for when, for instance, you have a form consisting of a parent and one or more child records. All the associations that you enable <tt>:nested_params</tt> on, will automatically have <tt>:autosave</tt> turned on as well. ## Examples for a has_one / belongs_to association ## @@@ ruby class Member < ActiveRecord::Base # This creates the following writer method: #avatar_attributes= has_one :avatar, :nested_params => true, :allow_destroy => true end # Adding an associated model: params[:member] # => { 'name' => 'jack', 'avatar_attributes' => { 'name' => 'smiley' }} member = Member.create(params[:member]) member.avatar.name # => 'smiley' # Updating the associated model: params # => { 'id' => '1', 'member' => { 'name' => 'joe', 'avatar_attributes' => { 'name' => 'sadly' }}} member = Member.find(params[:id]) member.update_attributes params[:member] member.avatar.name # => 'sadly' # Destroy the associated model by adding the <tt>_destroy</tt> attribute to the attributes hash. # Turn it on with the :allow_destroy option (Turned off by default): params[:member] # => { 'name' => 'joe', 'avatar_attributes' => { '_destroy' => '1' }} member.update_attributes params[:member] member.avatar # => nil @@@ ## Examples for a has_many / has_and_belongs_to_many association ## @@@ ruby class Member < ActiveRecord::Base # This creates the following writer method: #posts_attributes= has_many :posts, :nested_params => true, :destroy_missing => true, :allow_destroy => true end # Creating associated models. Note that no records will be instantiated for any empty hashes: params[:member] # => { 'name' => 'joe', 'posts_attributes' => { 'new_12345' => { 'title' => 'first psot' }, 'new_54321' => { 'title' => 'other post' }, 'new_67890' => { 'title' => '' } # This one is empty and will not be instantiated. }} member = Member.create(params[:member]) member.posts.length # => 2 member.posts.first.title # => 'first psot' member.posts.last.title # => 'other post' # Updating the associated models: params[:member] # => { 'name' => 'joe', 'posts_attributes' => { '1' => { 'title' => '[UPDATED] first psot' }, '2' => { 'title' => '[UPDATED] other post' } }} member.update_attributes params[:member] member.posts.first.title # => '[UPDATED] first psot' member.posts.last.title # => '[UPDATED] other post' # Destroy an associated model by leaving it out of the attributes hash. # Turn it on with the :destroy_missing option (Turned off by default): params[:member] # => { 'name' => 'joe', 'posts_attributes' => { '2' => { 'title' => '[UPDATED] other post is now the only post' } }} member.update_attributes params[:member] member.posts.length # => 1 member.posts.first.title # => '[UPDATED] other post is now the only post' # Or destroy an associated model by adding the <tt>_destroy</tt> attribute to the attributes hash. # Turn it on with the :allow_destroy option (Turned off by default): params[:member] # => { 'name' => 'joe', 'posts_attributes' => { '2' => { '_destroy' => '1' } }} member.update_attributes params[:member] member.posts.length # => 1 @@@ ## Examples of FormBuilder#fields_for with a has_one / belongs_to association ## @@@ ruby <% form_for @person, :url => { :action => "update" } do |person_form| %> ... <% person_form.fields_for :address do |address_fields| %> Street : <%= address_fields.text_field :street %> Zip code: <%= address_fields.text_field :zip_code %> <% end %> <% end %> @@@ ## Examples of FormBuilder#fields_for with a has_many / has_and_belongs_to_many association ## @@@ ruby <% form_for @person, :url => { :action => "update" } do |person_form| %> ... <% person_form.fields_for :projects do |project_fields| %> Name: <%= project_fields.text_field :name %> <% end %> <% end %> @@@ Note: The block given to #fields_for will be repeated for each record and can optionally take the record instance as a second argument. # Discussion # * Most of the implementation has been discussed in this thread: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/3c61e00916c365e5/ad1d4e40da933243 * I added the '_destroy' option as sugegested by Josh Susser, but I think that it will also require some extra support. Maybe in the form of a new FormBuilder method like #destroy, which would generate a checkbox for a record. * I named the option :nested_params as in our original plugin, could also be named :accessible. * Docs could probably be improved, I'd love feedback from people who read them. * I have a fork of Ryan Bates's complex-form-examples in which I use these functionalities: http://github.com/alloy/complex-form-examples/tree/alloy-nested_params_merged_in_rails This is the same problem :accessible tackled, but with support for creation/updating/destroying associated records. # What's in the patch? # * AutosaveAssociation, which as the name implies automatically saves associations, not only on create as is the default. * NestedParams, which is my take on this problem. It creates/updates/ destroys associations. It uses AutosaveAssociation. * FormBuilder with NestedParams support, which adds code to #fields_for for handling NestedParams enabled models. * A few general patches not necessarily related to this new functionality. Namely: * Added mattr_accessor's for valid_keys_for_has_one_through_association & valid_keys_for_has_and_belongs_to_many_association. http://github.com/alloy/rails/commit/bdb4b34197544c473d369058c4c9609787f35ad0 * Added a association instance get and set method, to dry up the associations code. http://github.com/alloy/rails/commit/e5dff966083030aeca9bb40890b92c04f9018357 http://github.com/alloy/rails/commit/e4822d2a9d0aa047966335187ce78e40bb5488af * Remove MySQL BEGIN and COMMIT queries from $queries_executed before asserting number of queries. http://github.com/alloy/rails/commit/fbcfcec2fd320ff913b83aa619ee94c636199a10 # Examples # _Taken from the docs._ When the <tt>:nested_params</tt> option is enabled an extra attributes writer will be created for the association. The attributes writer allows attributes of the associated model to be set directly with a hash. This is handy for when, for instance, you have a form consisting of a parent and one or more child records. All the associations that you enable <tt>:nested_params</tt> on, will automatically have <tt>:autosave</tt> turned on as well. ## Examples for a has_one / belongs_to association ## @@@ ruby class Member < ActiveRecord::Base # This creates the following writer method: #avatar_attributes= has_one :avatar, :nested_params => true, :allow_destroy => true end # Adding an associated model: params[:member] # => { 'name' => 'jack', 'avatar_attributes' => { 'name' => 'smiley' }} member = Member.create(params[:member]) member.avatar.name # => 'smiley' # Updating the associated model: params # => { 'id' => '1', 'member' => { 'name' => 'joe', 'avatar_attributes' => { 'name' => 'sadly' }}} member = Member.find(params[:id]) member.update_attributes params[:member] member.avatar.name # => 'sadly' # Destroy the associated model by adding the <tt>_destroy</tt> attribute to the attributes hash. # Turn it on with the :allow_destroy option (Turned off by default): params[:member] # => { 'name' => 'joe', 'avatar_attributes' => { '_destroy' => '1' }} member.update_attributes params[:member] member.avatar # => nil @@@ ## Examples for a has_many / has_and_belongs_to_many association ## @@@ ruby class Member < ActiveRecord::Base # This creates the following writer method: #posts_attributes= has_many :posts, :nested_params => true, :destroy_missing => true, :allow_destroy => true end # Creating associated models. Note that no records will be instantiated for any empty hashes: params[:member] # => { 'name' => 'joe', 'posts_attributes' => { 'new_12345' => { 'title' => 'first psot' }, 'new_54321' => { 'title' => 'other post' }, 'new_67890' => { 'title' => '' } # This one is empty and will not be instantiated. }} member = Member.create(params[:member]) member.posts.length # => 2 member.posts.first.title # => 'first psot' member.posts.last.title # => 'other post' # Updating the associated models: params[:member] # => { 'name' => 'joe', 'posts_attributes' => { '1' => { 'title' => '[UPDATED] first psot' }, '2' => { 'title' => '[UPDATED] other post' } }} member.update_attributes params[:member] member.posts.first.title # => '[UPDATED] first psot' member.posts.last.title # => '[UPDATED] other post' # Destroy an associated model by leaving it out of the attributes hash. # Turn it on with the :destroy_missing option (Turned off by default): params[:member] # => { 'name' => 'joe', 'posts_attributes' => { '2' => { 'title' => '[UPDATED] other post is now the only post' } }} member.update_attributes params[:member] member.posts.length # => 1 member.posts.first.title # => '[UPDATED] other post is now the only post' # Or destroy an associated model by adding the <tt>_destroy</tt> attribute to the attributes hash. # Turn it on with the :allow_destroy option (Turned off by default): params[:member] # => { 'name' => 'joe', 'posts_attributes' => { '2' => { '_destroy' => '1' } }} member.update_attributes params[:member] member.posts.length # => 1 @@@ ## Examples of FormBuilder#fields_for with a has_one / belongs_to association ## @@@ ruby <% form_for @person, :url => { :action => "update" } do |person_form| %> ... <% person_form.fields_for :address do |address_fields| %> Street : <%= address_fields.text_field :street %> Zip code: <%= address_fields.text_field :zip_code %> <% end %> <% end %> @@@ ## Examples of FormBuilder#fields_for with a has_many / has_and_belongs_to_many association ## @@@ ruby <% form_for @person, :url => { :action => "update" } do |person_form| %> ... <% person_form.fields_for :projects do |project_fields| %> Name: <%= project_fields.text_field :name %> <% end %> <% end %> @@@ Note: The block given to #fields_for will be repeated for each record and can optionally take the record instance as a second argument. # Discussion # * Most of the implementation has been discussed in this thread: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/3c61e00916c365e5/ad1d4e40da933243 * I added the '_destroy' option as sugegested by Josh Susser, but I think that it will also require some extra support. Maybe in the form of a new FormBuilder method like #destroy, which would generate a checkbox for a record. * I named the option :nested_params as in our original plugin, could also be named :accessible. * Docs could probably be improved, I'd love feedback from people who read them. * I have a fork of Ryan Bates's complex-form-examples in which I use these functionalities: http://github.com/alloy/complex-form-examples/tree/alloy-nested_params_merged_in_rails <div><p>This is the same problem :accessible tackled, but with support for creation/updating/destroying associated records.</p> <h1>What's in the patch?</h1> <ul> <li>AutosaveAssociation, which as the name implies automatically saves associations, not only on create as is the default.</li> <li>NestedParams, which is my take on this problem. It creates/updates/ destroys associations. It uses AutosaveAssociation.</li> <li>FormBuilder with NestedParams support, which adds code to #fields_for for handling NestedParams enabled models.</li> <li>A few general patches not necessarily related to this new functionality. Namely: <ul> <li>Added mattr_accessor's for valid_keys_for_has_one_through_association &amp; valid_keys_for_has_and_belongs_to_many_association. <a href="http://github.com/alloy/rails/commit/bdb4b34197544c473d369058c4c9609787f35ad0"> http://github.com/alloy/rails/co...</a></li> <li>Added a association instance get and set method, to dry up the associations code. <a href="http://github.com/alloy/rails/commit/e5dff966083030aeca9bb40890b92c04f9018357"> http://github.com/alloy/rails/co...</a> <a href="http://github.com/alloy/rails/commit/e4822d2a9d0aa047966335187ce78e40bb5488af"> http://github.com/alloy/rails/co...</a></li> <li>Remove MySQL BEGIN and COMMIT queries from $queries_executed before asserting number of queries. <a href="http://github.com/alloy/rails/commit/fbcfcec2fd320ff913b83aa619ee94c636199a10"> http://github.com/alloy/rails/co...</a></li> </ul> </li> </ul> <h1>Examples</h1> <p><em>Taken from the docs.</em></p> <p>When the :nested_params option is enabled an extra attributes writer will be created for the association. The attributes writer allows attributes of the associated model to be set directly with a hash. This is handy for when, for instance, you have a form consisting of a parent and one or more child records.</p> <p>All the associations that you enable :nested_params on, will automatically have :autosave turned on as well.</p> <h2>Examples for a has_one / belongs_to association</h2> <pre><code class="ruby"> class Member &lt; ActiveRecord::Base # This creates the following writer method: #avatar_attributes= has_one :avatar, :nested_params =&gt; true, :allow_destroy =&gt; true end # Adding an associated model: params[:member] # =&gt; { 'name' =&gt; 'jack', 'avatar_attributes' =&gt; { 'name' =&gt; 'smiley' }} member = Member.create(params[:member]) member.avatar.name # =&gt; 'smiley' # Updating the associated model: params # =&gt; { 'id' =&gt; '1', 'member' =&gt; { 'name' =&gt; 'joe', 'avatar_attributes' =&gt; { 'name' =&gt; 'sadly' }}} member = Member.find(params[:id]) member.update_attributes params[:member] member.avatar.name # =&gt; 'sadly' # Destroy the associated model by adding the &lt;tt&gt;_destroy&lt;/tt&gt; attribute to the attributes hash. # Turn it on with the :allow_destroy option (Turned off by default): params[:member] # =&gt; { 'name' =&gt; 'joe', 'avatar_attributes' =&gt; { '_destroy' =&gt; '1' }} member.update_attributes params[:member] member.avatar # =&gt; nil </code></pre> <h2>Examples for a has_many / has_and_belongs_to_many association</h2> <pre><code class="ruby"> class Member &lt; ActiveRecord::Base # This creates the following writer method: #posts_attributes= has_many :posts, :nested_params =&gt; true, :destroy_missing =&gt; true, :allow_destroy =&gt; true end # Creating associated models. Note that no records will be instantiated for any empty hashes: params[:member] # =&gt; { 'name' =&gt; 'joe', 'posts_attributes' =&gt; { 'new_12345' =&gt; { 'title' =&gt; 'first psot' }, 'new_54321' =&gt; { 'title' =&gt; 'other post' }, 'new_67890' =&gt; { 'title' =&gt; '' } # This one is empty and will not be instantiated. }} member = Member.create(params[:member]) member.posts.length # =&gt; 2 member.posts.first.title # =&gt; 'first psot' member.posts.last.title # =&gt; 'other post' # Updating the associated models: params[:member] # =&gt; { 'name' =&gt; 'joe', 'posts_attributes' =&gt; { '1' =&gt; { 'title' =&gt; '[UPDATED] first psot' }, '2' =&gt; { 'title' =&gt; '[UPDATED] other post' } }} member.update_attributes params[:member] member.posts.first.title # =&gt; '[UPDATED] first psot' member.posts.last.title # =&gt; '[UPDATED] other post' # Destroy an associated model by leaving it out of the attributes hash. # Turn it on with the :destroy_missing option (Turned off by default): params[:member] # =&gt; { 'name' =&gt; 'joe', 'posts_attributes' =&gt; { '2' =&gt; { 'title' =&gt; '[UPDATED] other post is now the only post' } }} member.update_attributes params[:member] member.posts.length # =&gt; 1 member.posts.first.title # =&gt; '[UPDATED] other post is now the only post' # Or destroy an associated model by adding the &lt;tt&gt;_destroy&lt;/tt&gt; attribute to the attributes hash. # Turn it on with the :allow_destroy option (Turned off by default): params[:member] # =&gt; { 'name' =&gt; 'joe', 'posts_attributes' =&gt; { '2' =&gt; { '_destroy' =&gt; '1' } }} member.update_attributes params[:member] member.posts.length # =&gt; 1 </code></pre> <h2>Examples of FormBuilder#fields_for with a has_one / belongs_to association</h2> <pre><code class="ruby"> &lt;% form_for @person, :url =&gt; { :action =&gt; &quot;update&quot; } do |person_form| %&gt; ... &lt;% person_form.fields_for :address do |address_fields| %&gt; Street : &lt;%= address_fields.text_field :street %&gt; Zip code: &lt;%= address_fields.text_field :zip_code %&gt; &lt;% end %&gt; &lt;% end %&gt; </code></pre> <h2>Examples of FormBuilder#fields_for with a has_many / has_and_belongs_to_many association</h2> <pre><code class="ruby"> &lt;% form_for @person, :url =&gt; { :action =&gt; &quot;update&quot; } do |person_form| %&gt; ... &lt;% person_form.fields_for :projects do |project_fields| %&gt; Name: &lt;%= project_fields.text_field :name %&gt; &lt;% end %&gt; &lt;% end %&gt; </code></pre> <p>Note: The block given to #fields_for will be repeated for each record and can optionally take the record instance as a second argument.</p> <h1>Discussion</h1> <ul> <li>Most of the implementation has been discussed in this thread: <a href="http://groups.google.com/group/rubyonrails-core/browse_thread/thread/3c61e00916c365e5/ad1d4e40da933243"> http://groups.google.com/group/r...</a></li> <li>I added the '_destroy' option as sugegested by Josh Susser, but I think that it will also require some extra support. Maybe in the form of a new FormBuilder method like #destroy, which would generate a checkbox for a record.</li> <li>I named the option :nested_params as in our original plugin, could also be named :accessible.</li> <li>Docs could probably be improved, I'd love feedback from people who read them.</li> <li>I have a fork of Ryan Bates's complex-form-examples in which I use these functionalities: <a href="http://github.com/alloy/complex-form-examples/tree/alloy-nested_params_merged_in_rails"> http://github.com/alloy/complex-...</a></li> </ul></div> 0 This is the same problem :accessible tackled, but with support for creation/updating/destroying associated records. _Note: I have updated the patches for edge and normalized them again. I removed the old documentation here because it just clobbers the whole page._ ## What's in the patch? ## * AutosaveAssociation, which as the name implies automatically saves associations, not only on create as is the default. * NestedAttributes, which is my take on this problem. It creates/updates/ destroys associations. (It uses AutosaveAssociation.) * FormBuilder with NestedAttributes support, which adds code to #fields_for for handling, amongst others, NestedAttributes models. ## Examples ## Please see the documentation of AutosaveAssociation, NestedAttributes, and FormBuilder#fields_for. Also expect to see some more elaborate explanation on a well known blog in the near future. I will add the url here once that has been done. You can also checkout my fork of Ryan Bates's complex-form-examples which uses it: http://github.com/alloy/complex-form-examples/commits/nested_attributes ## Patches ## The AutosaveAssociation and NestedAttributes patches rely on the following patches: * Accessor methods for association instances. #1728 * Remove transaction queries from assert_queries count. #1732 After applying those two you can apply the AutosaveAssociation patch and finally the NestedAttributes patch. <div><p>This is the same problem :accessible tackled, but with support for creation/updating/destroying associated records.</p> <p><em>Note: I have updated the patches for edge and normalized them again. I removed the old documentation here because it just clobbers the whole page.</em></p> <h2>What's in the patch?</h2> <ul> <li>AutosaveAssociation, which as the name implies automatically saves<br> associations, not only on create as is the default.</li> <li>NestedAttributes, which is my take on this problem. It creates/updates/ destroys associations. (It uses AutosaveAssociation.)</li> <li>FormBuilder with NestedAttributes support, which adds code to #fields_for for handling, amongst others, NestedAttributes models.</li> </ul> <h2>Examples</h2> <p>Please see the documentation of AutosaveAssociation, NestedAttributes, and FormBuilder#fields_for. Also expect to see some more elaborate explanation on a well known blog in the near future. I will add the url here once that has been done.</p> <p>You can also checkout my fork of Ryan Bates's complex-form-examples which uses it: <a href="http://github.com/alloy/complex-form-examples/commits/nested_attributes"> http://github.com/alloy/complex-...</a></p> <h2>Patches</h2> <p>The AutosaveAssociation and NestedAttributes patches rely on the following patches:</p> <ul> <li>Accessor methods for association instances. <a href="/projects/8994/tickets/1728" title="Ticket #1728">#1728</a></li> <li>Remove transaction queries from assert_queries count. <a href="/projects/8994/tickets/1732" title="Ticket #1732">#1732</a></li> </ul> <p>After applying those two you can apply the AutosaveAssociation patch and finally the NestedAttributes patch.</p></div> false 2008-10-11T17:31:12+01:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-21T15:56:04+00:00 8406 Eloy Duran Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 In the following example: # Creating associated models. Note that no records will be instantiated for any empty hashes: params[:member] # => { 'name' => 'joe', 'posts_attributes' => { 'new_12345' => { 'title' => 'first psot' }, 'new_54321' => { 'title' => 'other post' }, 'new_67890' => { 'title' => '' } # This one is empty and will not be instantiated. }} , what significance does `new_12345` and the other keys have? Would it make more sense to have the `posts_attributes` be an array of hashes instead? <div><p>In the following example:</p> <p># Creating associated models. Note that no records will be instantiated for any empty hashes: params[:member] # =&gt; { 'name' =&gt; 'joe', 'posts_attributes' =&gt; {</p> <pre> <code>'new_12345' =&gt; { 'title' =&gt; 'first psot' }, 'new_54321' =&gt; { 'title' =&gt; 'other post' }, 'new_67890' =&gt; { 'title' =&gt; '' } # This one is empty and will not be instantiated. </code> </pre> <p>}} , what significance does <code>new_12345</code> and the other keys have?</p> <p>Would it make more sense to have the <code>posts_attributes</code> be an array of hashes instead?</p></div> false 2008-10-11T20:15:12+01:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-10-11T20:15:14+01:00 17949 Daniel Schierbeck Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 The last example should of course have been: # Creating associated models. Note that no records will be instantiated for any empty hashes: params[:member] # => { 'name' => 'joe', 'posts_attributes' => { 'new_12345' => { 'title' => 'first psot' }, 'new_54321' => { 'title' => 'other post' }, 'new_67890' => { 'title' => '' } # This one is empty and will not be instantiated. }} <div><p>The last example should of course have been:</p> <pre> <code># Creating associated models. Note that no records will be instantiated for any empty hashes: params[:member] # =&gt; { 'name' =&gt; 'joe', 'posts_attributes' =&gt; { 'new_12345' =&gt; { 'title' =&gt; 'first psot' }, 'new_54321' =&gt; { 'title' =&gt; 'other post' }, 'new_67890' =&gt; { 'title' =&gt; '' } # This one is empty and will not be instantiated. }} </code> </pre></div> false 2008-10-11T20:16:23+01:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-10-11T20:16:25+01:00 17949 Daniel Schierbeck Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 An array of hashes for new records is also supported. The “new_123” keys however, are so that you can mix existing records with new ones. These keys are generated by the modified FormBuilder#fields_for for new records, or you can create them yourself if your using an API for instance. <div><p>An array of hashes for new records is also supported.</p> <p>The &#8220;new_123&#8221; keys however, are so that you can mix existing records with new ones. These keys are generated by the modified FormBuilder#fields_for for new records, or you can create them yourself if your using an API for instance.</p></div> false 2008-10-12T12:43:29+01:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-10-12T12:43:33+01:00 8406 Eloy Duran Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 I should have added that a hash is what gets created by the parameter parser if you have records with an id and an array is what gets created for a collection of records without an id. So for this to work, in a scenario where you have mixed new and existing records, it should support a hash and not an array and thus should have at least some sort of index key for each record. <div><p>I should have added that a hash is what gets created by the parameter parser if you have records with an id and an array is what gets created for a collection of records without an id. So for this to work, in a scenario where you have mixed new and existing records, it should support a hash and not an array and thus should have at least some sort of index key for each record.</p></div> false 2008-10-12T12:51:54+01:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-10-12T12:51:54+01:00 8406 Eloy Duran Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 0 Added a new patch with: - better NestedParams docs by Manfred Stienstra. - #acts_like_hash? for Hash and ActiveSupport::OrderedHash - updated to work with current edge Rails (09c1718). <div><p>Added a new patch with: - better NestedParams docs by Manfred Stienstra. - #acts_like_hash? for Hash and ActiveSupport::OrderedHash - updated to work with current edge Rails (09c1718).</p></div> false 2008-10-15T11:14:52+01:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-10-15T11:14:55+01:00 8406 Eloy Duran Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 This is the best and most complete approach to that issue that I've seen to far. +1 from my side, but I don't think it should make it into 2.2 as you can never be sure it doesn't break something. That said, do you think you could make this a heavily monkey-patching plugin or gem for the time being? I would love to use it for my next project, together with considerably stable 2.2. <div><p>This is the best and most complete approach to that issue that I've seen to far.</p> <p>+1 from my side, but I don't think it should make it into 2.2 as you can never be sure it doesn't break something.</p> <p>That said, do you think you could make this a heavily monkey-patching plugin or gem for the time being? I would love to use it for my next project, together with considerably stable 2.2.</p></div> false 2008-10-16T16:25:47+01:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-10-16T16:25:53+01:00 19954 Pascal Ehlert Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 @Pascal: If I find some time I'll see about back porting into the plugin. I myself think it would need more testing, so 2.2 is probably too close already. <div><p>@Pascal: If I find some time I'll see about back porting into the plugin.</p> <p>I myself think it would need more testing, so 2.2 is probably too close already.</p></div> false 2008-10-16T17:24:25+01:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-10-16T17:24:29+01:00 8406 Eloy Duran Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 looks like a winner to me +1 <div><p>looks like a winner to me +1</p></div> false 2008-10-21T05:40:06+01:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-10-21T05:40:08+01:00 11268 linoj Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 I like this patch a lot, but have a few comments. The whole autosave thing seems flawed, as it's currently implemented. Why save all associations all the time? We have changed? and friends to help us decide when to save. Saving associations all the time will emit a lot of queries. But, it's possible that I missed something, since I didn't read every line. I hate the name. params is an action_controller term. They should have some other name in active_record, since they're not tied to external params. Perhaps :attributes => true ? Lastly, I'm sorry to say that I don't feel that the code quality is really there. I find the methods very long, winding and difficult to read. My big problem with this patch is that I've been staring at it for quite a while, and I still don't feel like I really understand how it works. I really think that it would be nice to refactor this code in to a class that handles all the logic around saving and validating collections of active_record objects. I have been working on something similar for my active_presenter plugin, but haven't got anything quite finished yet. It would be a lot more flexible that way, because you could use it for more than just associations (i.e. collections of top level objects in one form). It would also provide better encapsulation and testability. <div><p>I like this patch a lot, but have a few comments.</p> <p>The whole autosave thing seems flawed, as it's currently implemented. Why save all associations all the time? We have changed? and friends to help us decide when to save. Saving associations all the time will emit a lot of queries. But, it's possible that I missed something, since I didn't read every line.</p> <p>I hate the name. params is an action_controller term. They should have some other name in active_record, since they're not tied to external params. Perhaps :attributes =&gt; true ?</p> <p>Lastly, I'm sorry to say that I don't feel that the code quality is really there. I find the methods very long, winding and difficult to read. My big problem with this patch is that I've been staring at it for quite a while, and I still don't feel like I really understand how it works.</p> <p>I really think that it would be nice to refactor this code in to a class that handles all the logic around saving and validating collections of active_record objects. I have been working on something similar for my active_presenter plugin, but haven't got anything quite finished yet. It would be a lot more flexible that way, because you could use it for more than just associations (i.e. collections of top level objects in one form). It would also provide better encapsulation and testability.</p></div> false 2008-11-22T16:49:36+00:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-11-22T16:49:38+00:00 9497 James Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 “The whole autosave thing seems flawed, as it's currently implemented. Why save all associations all the time? We have changed? and friends to help us decide when to save. Saving associations all the time will emit a lot of queries. But, it's possible that I missed something, since I didn't read every line.” ActiveRecord::Base#save shouldn't actually perform any queries if the record is not changed? So there's no need to duplicate that code. I'll double check though if it really doesn't, when I update the patch one of these days. “I hate the name. params is an action_controller term. They should have some other name in active_record, since they're not tied to external params. Perhaps :attributes => true ?” I agree. However just :attributes doesn't tell me enough. How about :nested_attributes ? “Lastly, I'm sorry to say that I don't feel that the code quality is really there. I find the methods very long, winding and difficult to read. My big problem with this patch is that I've been staring at it for quite a while, and I still don't feel like I really understand how it works.” The long methods were meant as being descriptive. Please tell me which methods and why you find they are hard to grok. “I really think that it would be nice to refactor this code in to a class that handles all the logic around saving and validating collections of active_record objects. I have been working on something similar for my active_presenter plugin, but haven't got anything quite finished yet. It would be a lot more flexible that way, because you could use it for more than just associations (i.e. collections of top level objects in one form). It would also provide better encapsulation and testability.” I haven't had a need for that in the application that we used it in. Thanks, Eloy <div><p>&#8220;The whole autosave thing seems flawed, as it's currently implemented. Why save all associations all the time? We have changed? and friends to help us decide when to save. Saving associations all the time will emit a lot of queries. But, it's possible that I missed something, since I didn't read every line.&#8221;</p> <p>ActiveRecord::Base#save shouldn't actually perform any queries if the record is not changed? So there's no need to duplicate that code. I'll double check though if it really doesn't, when I update the patch one of these days.</p> <p>&#8220;I hate the name. params is an action_controller term. They should have some other name in active_record, since they're not tied to external params. Perhaps :attributes =&gt; true ?&#8221;</p> <p>I agree. However just :attributes doesn't tell me enough. How about :nested_attributes ?</p> <p>&#8220;Lastly, I'm sorry to say that I don't feel that the code quality is really there. I find the methods very long, winding and difficult to read. My big problem with this patch is that I've been staring at it for quite a while, and I still don't feel like I really understand how it works.&#8221;</p> <p>The long methods were meant as being descriptive. Please tell me which methods and why you find they are hard to grok.</p> <p>&#8220;I really think that it would be nice to refactor this code in to a class that handles all the logic around saving and validating collections of active_record objects. I have been working on something similar for my active_presenter plugin, but haven't got anything quite finished yet. It would be a lot more flexible that way, because you could use it for more than just associations (i.e. collections of top level objects in one form). It would also provide better encapsulation and testability.&#8221;</p> <p>I haven't had a need for that in the application that we used it in.</p> <p>Thanks, Eloy</p></div> false 2008-11-22T18:03:27+00:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-11-22T18:03:31+00:00 8406 Eloy Duran Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 They're not nested in the context of the declaration though. You don't say has_many :nested_class_name =>... You say :class_name. The fact that it's has_many implies that it's nested. One example of code that I find difficult to grok is define_nested_params_writer_for_collection_association. It goes up to about 12 levels of indentation with many nested conditionals and other statements. The method is about 30 lines long, which makes it easy to lose context as you read through it. Nested conditionals like that are ugly, and there's really no reason to use them in ruby. There are other examples in this set of patches. I don't understand your point about not needing that in your application. You don't need well factored, properly encapsulated code? You may not need the feature of editing many top-level models at once, but adding all this code to one place blurs responsibilities, and means that extracting it to do anything else later on is going to be impossible. I'm currently working on a refactoring of action_pack, and let me tell you, the lack of encapsulation is making it VERY hard. ActionController::Base has about a million responsibilities that are all tangled up in eachother. That makes it really bloody hard to refactor. Really, really bloody hard. <div><p>They're not nested in the context of the declaration though. You don't say has_many :nested_class_name =&gt;... You say :class_name. The fact that it's has_many implies that it's nested.</p> <p>One example of code that I find difficult to grok is define_nested_params_writer_for_collection_association. It goes up to about 12 levels of indentation with many nested conditionals and other statements. The method is about 30 lines long, which makes it easy to lose context as you read through it. Nested conditionals like that are ugly, and there's really no reason to use them in ruby. There are other examples in this set of patches.</p> <p>I don't understand your point about not needing that in your application. You don't need well factored, properly encapsulated code? You may not need the feature of editing many top-level models at once, but adding all this code to one place blurs responsibilities, and means that extracting it to do anything else later on is going to be impossible.</p> <p>I'm currently working on a refactoring of action_pack, and let me tell you, the lack of encapsulation is making it VERY hard. ActionController::Base has about a million responsibilities that are all tangled up in eachother. That makes it really bloody hard to refactor. Really, really bloody hard.</p></div> false 2008-11-22T18:20:44+00:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-11-22T18:20:45+00:00 9497 James Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 “They're not nested in the context of the declaration though. You don't say has_many :nested_class_name =>... You say :class_name. The fact that it's has_many implies that it's nested.” :attributes is still too abstract for me. “I don't understand your point about not needing that in your application. You don't need well factored, properly encapsulated code? You may not need the feature of editing many top-level models at once, but adding all this code to one place blurs responsibilities, and means that extracting it to do anything else later on is going to be impossible.” Obviously the latter. <div><p>&#8220;They're not nested in the context of the declaration though. You don't say has_many :nested_class_name =&gt;... You say :class_name. The fact that it's has_many implies that it's nested.&#8221;</p> <p>:attributes is still too abstract for me.</p> <p>&#8220;I don't understand your point about not needing that in your application. You don't need well factored, properly encapsulated code? You may not need the feature of editing many top-level models at once, but adding all this code to one place blurs responsibilities, and means that extracting it to do anything else later on is going to be impossible.&#8221;</p> <p>Obviously the latter.</p></div> false 2008-11-23T12:26:15+00:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-11-23T12:26:21+00:00 8406 Eloy Duran Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 1 Uploaded an updated patch for current HEAD. I changed the option from :nested_params to :accept_nested_attributes, which should more clearly express it's intent. Also the big method in ActiveRecord::NestedAttributes has been split up into smaller methods. <div><p>Uploaded an updated patch for current HEAD.</p> <p>I changed the option from :nested_params to :accept_nested_attributes, which should more clearly express it's intent. Also the big method in ActiveRecord::NestedAttributes has been split up into smaller methods.</p></div> false 2008-12-03T20:19:07+00:00 8406 --- {} 9903 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-12-03T20:19:13+00:00 8406 Eloy Duran Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 2.x 141 1 false 2008-12-04T11:04:03+00:00 8406 --- :milestone: 9903 :assigned_user: 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-12-04T11:04:07+00:00 1366 Pratik Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 1 Could you rebase the patch down to one changeset, it's pretty hard to follow when spread over several changes. Also, the use of alias_method_chain isn't needed here. You should be able to make those changes inline. <div><p>Could you rebase the patch down to one changeset, it's pretty hard to follow when spread over several changes.</p> <p>Also, the use of alias_method_chain isn't needed here. You should be able to make those changes inline.</p></div> false 2008-12-10T19:18:53+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-12-10T19:18:58+00:00 141 Michael Koziarski Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 1 I created a flattened patch, which is updated for edge again. The changes to OrderedHash caused some breakage, so this patch depends on the patch in ticket #1559. <div><p>I created a flattened patch, which is updated for edge again. The changes to OrderedHash caused some breakage, so this patch depends on the patch in ticket <a href="/projects/8994/tickets/1559" title="Ticket #1559">#1559</a>.</p></div> false 2008-12-11T13:48:51+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-12-11T13:48:53+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 1 Sorry that I missed this before rolling yet another solution! Some thoughts on the patch: * Form builders are nice! There's something I'm missing in my plugin. * I'm not a fan of the new_1234 hash keys. Are those actually meaningful? I didn't see if they're parsed in the code, but they're still used in the examples and tests and that's a bit confusing. * Your patch ignores new records that are "empty". That's how I did this back in ActiveScaffold, and it doesn't work in practice. You will run into problems with form elements that always have values like date selectors, radio buttons, or dropdowns. * I think you're supporting too many different ways of doing things. We should be opinionated, right? Let's not support deleting records with missing rows. That may work sometimes, but not always, whereas the :_destroy key does work always (and can solve the problem with empty new records, too). * I don't like :autosave as an option. It's too much configuration for me. I would rather have an intelligent autosave that simply worked as expected. * The :allow_destroy, :destroy_missing, and :accept_nested_attributes options don't feel like association configuration. That is, they don't relate to how the association is set up. Instead they relate to how the association responds to mass assignment from a form. It just feels ... slightly off. I'd rather keep the association setup all database-related with foreign keys, class names, conditions, etc. Please feel free to steal any ideas from my new plugin at http://github.com/cainlevy/nested_assignment/tree/master. An example implementation is available at http://github.com/cainlevy/complex-form-examples/tree/cainlevy. -Lance <div><p>Sorry that I missed this before rolling yet another solution!</p> <p>Some thoughts on the patch:</p> <ul> <li>Form builders are nice! There's something I'm missing in my plugin.</li> <li>I'm not a fan of the new_1234 hash keys. Are those actually meaningful? I didn't see if they're parsed in the code, but they're still used in the examples and tests and that's a bit confusing.</li> <li>Your patch ignores new records that are "empty". That's how I did this back in ActiveScaffold, and it doesn't work in practice. You will run into problems with form elements that always have values like date selectors, radio buttons, or dropdowns.</li> <li>I think you're supporting too many different ways of doing things. We should be opinionated, right? Let's not support deleting records with missing rows. That may work sometimes, but not always, whereas the :_destroy key does work always (and can solve the problem with empty new records, too).</li> <li>I don't like :autosave as an option. It's too much configuration for me. I would rather have an intelligent autosave that simply worked as expected.</li> <li>The :allow_destroy, :destroy_missing, and :accept_nested_attributes options don't feel like association configuration. That is, they don't relate to how the association is set up. Instead they relate to how the association responds to mass assignment from a form. It just feels ... slightly off. I'd rather keep the association setup all database-related with foreign keys, class names, conditions, etc.</li> </ul> <p>Please feel free to steal any ideas from my new plugin at <a href="http://github.com/cainlevy/nested_assignment/tree/master">http://github.com/cainlevy/neste...</a>. An example implementation is available at <a href="http://github.com/cainlevy/complex-form-examples/tree/cainlevy.%3C/p"> http://github.com/cainlevy/compl...</a>&gt;</p> <p>-Lance</p></div> false 2008-12-14T22:22:06+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-12-14T22:22:10+00:00 8964 cainlevy Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 1 When this will land in 2.3 ? <div><p>When this will land in 2.3 ?</p></div> false 2008-12-17T11:33:09+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-12-17T11:33:13+00:00 11785 Paweł Kondzior Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 1 I will first update the patch once more with some of the feedback from Lance, on this ticket but also by email. So _at least_ it won't be until I've had time for that, which will probably be in this/next week. <div><p>I will first update the patch once more with some of the feedback from Lance, on this ticket but also by email. So <em>at least</em> it won't be until I've had time for that, which will probably be in this/next week.</p></div> false 2008-12-17T12:24:31+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-12-17T12:24:36+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 1 I'm also travelling for a week or two but intend to take a closer look when I get back on deck. Things will slip a bit over the holidays, but we'll get there :) <div><p>I'm also travelling for a week or two but intend to take a closer look when I get back on deck.</p> <p>Things will slip a bit over the holidays, but we'll get there :)</p></div> false 2008-12-17T12:29:28+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-12-17T12:29:28+00:00 141 Michael Koziarski Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 1 This is Model#nested_changes proposal of implementation. changes format for one_to_one: http://pastie.org/341324 for collections there is only one difference, they are all in [] instead of directly hash: { "reflaction" => { :created => [{...}, {...}, ...] } There is no tests in this patch, and no nested_changes.clear after save. What do you thnik about this ? If there is place for such implementation here i can do the rest of issues that need to be solved here. BTW. there is a bug in assign_to_or_destroy_nested_attributes_records, it should throw NoRecord or similar exception for id that doesn't exsists. Now it throws nil.attributes= exception. <div><p>This is Model#nested_changes proposal of implementation.</p> <p>changes format for one_to_one: <a href="http://pastie.org/341324">http://pastie.org/341324</a></p> <p>for collections there is only one difference, they are all in [] instead of directly hash: { "reflaction" =&gt; { :created =&gt; [{...}, {...}, ...] }</p> <p>There is no tests in this patch, and no nested_changes.clear after save.</p> <p>What do you thnik about this ? If there is place for such implementation here i can do the rest of issues that need to be solved here.</p> <p>BTW. there is a bug in assign_to_or_destroy_nested_attributes_records, it should throw NoRecord or similar exception for id that doesn't exsists. Now it throws nil.attributes= exception.</p></div> false 2008-12-17T16:05:51+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2008-12-17T16:05:55+00:00 11785 Paweł Kondzior Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 2 *bump* Any progress on this? I'm really curious to see this functionality in the core as none of the available plugins can keep up with the proposed patches. <div><p><em>bump</em> Any progress on this? I'm really curious to see this functionality in the core as none of the available plugins can keep up with the proposed patches.</p></div> false 2009-01-09T14:23:51+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-09T14:23:56+00:00 19954 Pascal Ehlert Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 2 It's still progressing, I just started discussing some stuff with Michael. So expect a new and hopefully final patch. <div><p>It's still progressing, I just started discussing some stuff with Michael. So expect a new and hopefully final patch.</p></div> false 2009-01-09T15:14:29+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-09T15:14:33+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 2 Excellent, I'm glad to hear that. I just thought it might not get the attention it deserves ;-) Thanks a lot for your hard work guys. <div><p>Excellent, I'm glad to hear that. I just thought it might not get the attention it deserves ;-)</p> <p>Thanks a lot for your hard work guys.</p></div> false 2009-01-09T15:26:29+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-09T15:26:35+00:00 19954 Pascal Ehlert Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 2 I know I'm late to the party, but I'd like to test and help contribute to the next patch if it's okay. Eloy, do you think we can communicate over email? ryan AT railscasts DOT com. <div><p>I know I'm late to the party, but I'd like to test and help contribute to the next patch if it's okay. Eloy, do you think we can communicate over email? ryan AT railscasts DOT com.</p></div> false 2009-01-09T16:40:39+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-09T16:40:44+00:00 5701 Ryan Bates Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 2 +1 <div><p>+1</p></div> false 2009-01-11T11:36:42+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-11T18:19:03+00:00 14415 Jérôme Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 2 +1 <div><p>+1</p></div> false 2009-01-12T09:05:11+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-12T09:05:12+00:00 18156 Nicolas Blanco Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 2 New AutosaveAssociation patch, updated for edge and normalized into 1 diff. <div><p>New AutosaveAssociation patch, updated for edge and normalized into 1 diff.</p></div> false 2009-01-21T15:57:05+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-21T15:57:11+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 New NestedAttributes patch, updated for edge and normalized into 1 diff. <div><p>New NestedAttributes patch, updated for edge and normalized into 1 diff.</p></div> false 2009-01-21T15:57:29+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-21T15:57:34+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 4 How will this handle validation for multiple records, e.g. when you have a project which has_many comments and in your form template you're using fields_for to render these, will validation errors for individual projects be added to the correct fields? (so that field_error_proc works out of the box). Also I saw that for has_one associations, you're adding an error for author.name to the parent model as author_name.. What if I'm having an actual author_name field on the parent? I think validation is the hardest part here and we should try to do it properly right away.. Why do we even need to add it to the parent model? Wouldn't it be sufficient and cleaner to just refactor the form helpers that actually add the errors so that they will look for errors in the associated objects? Last but not least there is a typo/broken sentence in line 205 of the nested_attributes patch. ;) Thanks a lot for your effort to finally get this right and if you need any help, let me know. I'd like to contribute as well, maybe you can get me into the boat? pascal DOT ehlert AT odadata DOT eu <div><p>How will this handle validation for multiple records, e.g. when you have a project which has_many comments and in your form template you're using fields_for to render these, will validation errors for individual projects be added to the correct fields? (so that field_error_proc works out of the box).</p> <p>Also I saw that for has_one associations, you're adding an error for author.name to the parent model as author_name.. What if I'm having an actual author_name field on the parent?</p> <p>I think validation is the hardest part here and we should try to do it properly right away.. Why do we even need to add it to the parent model? Wouldn't it be sufficient and cleaner to just refactor the form helpers that actually add the errors so that they will look for errors in the associated objects?</p> <p>Last but not least there is a typo/broken sentence in line 205 of the nested_attributes patch. ;)</p> <p>Thanks a lot for your effort to finally get this right and if you need any help, let me know. I'd like to contribute as well, maybe you can get me into the boat? pascal DOT ehlert AT odadata DOT eu</p></div> false 2009-01-21T16:42:33+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-21T16:42:36+00:00 19954 Pascal Ehlert Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 4 Yes the validations will be added to the correct fields, just as it is right now. If you have an author_name field on the parent and an author which has a name it would seem there is unnecessary overlap, so it seems as a non-issue to me at least for now. Unless someone can give me a real life example of breakage of course :) The validation messages are added to the parent because in our case I want only 1 error messages list at the top of the form instead of multiple ones breaking the complete layout (and it's ugly anyways). But note that of course the individual fields are still marked as a fieldWithErrors. Ah yes that sentence is wrong, thanks for reading it! If you would like to help out then please checkout the complex-form-examples and play with it and the patches. Thanks in advance :) <div><p>Yes the validations will be added to the correct fields, just as it is right now.</p> <p>If you have an author_name field on the parent and an author which has a name it would seem there is unnecessary overlap, so it seems as a non-issue to me at least for now. Unless someone can give me a real life example of breakage of course :)</p> <p>The validation messages are added to the parent because in our case I want only 1 error messages list at the top of the form instead of multiple ones breaking the complete layout (and it's ugly anyways). But note that of course the individual fields are still marked as a fieldWithErrors.</p> <p>Ah yes that sentence is wrong, thanks for reading it!</p> <p>If you would like to help out then please checkout the complex-form-examples and play with it and the patches. Thanks in advance :)</p></div> false 2009-01-21T17:01:59+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-21T17:02:03+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 4 Sounds good to me. Only the author_name issue kinda bugs me, it may be an unnecessary overlap in most cases, but can we justify to break peoples applications by saying "the field names they're using are wrong"? And your argument with the multiple lists is one more reason for me to patch error_messages_for instead of adding them to the parent model. It's not only the naming issue, it's also that it doesn't feel too clean for me to ignore the separation their. Just my 2 cents, I'd like to see some further discussion. (Although I'm strongly for getting this into core asap). <div><p>Sounds good to me.</p> <p>Only the author_name issue kinda bugs me, it may be an unnecessary overlap in most cases, but can we justify to break peoples applications by saying "the field names they're using are wrong"?</p> <p>And your argument with the multiple lists is one more reason for me to patch error_messages_for instead of adding them to the parent model. It's not only the naming issue, it's also that it doesn't feel too clean for me to ignore the separation their.</p> <p>Just my 2 cents, I'd like to see some further discussion. (Although I'm strongly for getting this into core asap).</p></div> false 2009-01-21T17:09:24+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-21T17:09:29+00:00 19954 Pascal Ehlert Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 4 Fixed error in sentence. Thanks Pascal. <div><p>Fixed error in sentence. Thanks Pascal.</p></div> false 2009-01-21T17:10:03+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-21T17:10:06+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 Well, willingly breaking someone's code would indeed be bad :) What I meant was that it's justified for _us_ to assume it won't break any code. And like I said, if someone would popup with a valid reason for why it breaks, I will definitely fix it. About the other issue, I personally think it's fine that the parent knows of the errors of its children. Because ultimately you are only dealing with that parent object and saving its children should be its responsibility so you should be able to query the possible errors. Maybe moving it into a separate Errors object would help? (#nested_errors) <div><p>Well, willingly breaking someone's code would indeed be bad :) What I meant was that it's justified for <em>us</em> to assume it won't break any code. And like I said, if someone would popup with a valid reason for why it breaks, I will definitely fix it.</p> <p>About the other issue, I personally think it's fine that the parent knows of the errors of its children. Because ultimately you are only dealing with that parent object and saving its children should be its responsibility so you should be able to query the possible errors. Maybe moving it into a separate Errors object would help? (#nested_errors)</p></div> false 2009-01-21T19:57:10+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-21T19:57:12+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 Yes, that was my thought as well.. Having a nested_errors accessor that directly queries the child error objects. That way we could keep it separated but it would still be accessible from the parent object (which indeed is a good idea). <div><p>Yes, that was my thought as well.. Having a nested_errors accessor that directly queries the child error objects.</p> <p>That way we could keep it separated but it would still be accessible from the parent object (which indeed is a good idea).</p></div> false 2009-01-21T23:47:40+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-21T23:47:43+00:00 19954 Pascal Ehlert Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 Updated the patch to remove the optional second argument for the fields_for block as discussed with Michael. The collection member is simply available through foo_form#object. <div><p>Updated the patch to remove the optional second argument for the fields_for block as discussed with Michael. The collection member is simply available through foo_form#object.</p></div> false 2009-01-22T10:44:47+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-22T10:44:51+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 @Pascal After giving it some more thought, and discussing with Michael, I have decided to mark this as a "could do later" TODO. (I have a few others as well.) I don't think it's an issue to deal with right away for this specific patch. Once the patch is applied I will create tickets for these TODO's. This should also, for instance, make it easier for you to work on if you wish. <div><p>@Pascal After giving it some more thought, and discussing with Michael, I have decided to mark this as a "could do later" TODO. (I have a few others as well.) I don't think it's an issue to deal with right away for this specific patch.</p> <p>Once the patch is applied I will create tickets for these TODO's. This should also, for instance, make it easier for you to work on if you wish.</p></div> false 2009-01-22T10:49:08+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-22T10:49:11+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 That's reasonable and speeding the process up a little is a good thing. :) Thanks again and I hope this will make it into trunk quickly now. I will then comment on the other tickets (with patches that time ;)). <div><p>That's reasonable and speeding the process up a little is a good thing. :) Thanks again and I hope this will make it into trunk quickly now.</p> <p>I will then comment on the other tickets (with patches that time ;)).</p></div> false 2009-01-22T11:32:25+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-22T11:32:29+00:00 19954 Pascal Ehlert Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 @Pascal Awesome, thanks again for your feedback. <div><p>@Pascal Awesome, thanks again for your feedback.</p></div> false 2009-01-22T12:17:12+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-22T12:17:14+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 New patch: Renamed accept_nested_attributes_for method to accepts_nested_attributes_for. <div><p>New patch: Renamed accept_nested_attributes_for method to accepts_nested_attributes_for.</p></div> false 2009-01-27T10:35:24+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-27T10:35:30+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 That patch doesn't apply to master any more. If you can rebase the latest version, I think we're good to go! <div><p>That patch doesn't apply to master any more. If you can rebase the latest version, I think we're good to go!</p></div> false 2009-01-29T04:20:23+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-29T04:20:26+00:00 141 Michael Koziarski Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 Updated nested_attributes.diff for edge. <div><p>Updated nested_attributes.diff for edge.</p></div> false 2009-01-29T08:31:33+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-29T08:31:37+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 I came across this via the Rails blog post. I'm interested because I have been working on solving a similar problem through a plugin I have called [Conductor](http://github.com/jonleighton/conductor/tree/master). My initial reaction is that this seems very good. I'm pleased to see the problem being addressed in core Rails; whilst I am happy with the API I've come up with for my plugin, this definitely requires less cognitive overhead, which is obviously a good thing. I'm not going to comment on the implementation (don't have time to study it properly), but with regard to the API I worry that putting this directly into ActiveRecord is a step too far. There's a lot of "hacking" in the syntax of the parameters which exist purely to overcome the limitations of HTTP parameters and HTML forms. (For instance "_delete", and "new_x".) That was the idea behind having a "conductor" as a separate object - it acts as a buffer between the controller in the model. However I think using a completely separate object is probably the opposite extreme and I wouldn't advocate putting that into Rails either. With regard to syntax for the parameters, I vastly prefer Approach 1 [here](http://gist.github.com/10793), as it contains nothing which is specific to HTTP/HTML. The issue with implementing it is communicating the array over HTTP and HTML validation of the form. In my conductor plugin I use an indexed hash like in approach 4. It's a bit more ugly but solves the problem. An ideal solution might be to have ActionController automatically convert "indexed" arrays from the request into "real" arrays in the params hash. I don't know though; perhaps that would be too magic. Anyway, in general I think this looks very promising, though I don't particularly like HTTP workarounds creeping into ActiveRecord. <div><p>I came across this via the Rails blog post. I'm interested because I have been working on solving a similar problem through a plugin I have called <a href="http://github.com/jonleighton/conductor/tree/master">Conductor</a>.</p> <p>My initial reaction is that this seems very good. I'm pleased to see the problem being addressed in core Rails; whilst I am happy with the API I've come up with for my plugin, this definitely requires less cognitive overhead, which is obviously a good thing.</p> <p>I'm not going to comment on the implementation (don't have time to study it properly), but with regard to the API I worry that putting this directly into ActiveRecord is a step too far. There's a lot of "hacking" in the syntax of the parameters which exist purely to overcome the limitations of HTTP parameters and HTML forms. (For instance "_delete", and "new_x".)</p> <p>That was the idea behind having a "conductor" as a separate object - it acts as a buffer between the controller in the model. However I think using a completely separate object is probably the opposite extreme and I wouldn't advocate putting that into Rails either.</p> <p>With regard to syntax for the parameters, I vastly prefer Approach 1 <a href="http://gist.github.com/10793">here</a>, as it contains nothing which is specific to HTTP/HTML. The issue with implementing it is communicating the array over HTTP and HTML validation of the form.</p> <p>In my conductor plugin I use an indexed hash like in approach 4. It's a bit more ugly but solves the problem. An ideal solution might be to have ActionController automatically convert "indexed" arrays from the request into "real" arrays in the params hash. I don't know though; perhaps that would be too magic.</p> <p>Anyway, in general I think this looks very promising, though I don't particularly like HTTP workarounds creeping into ActiveRecord.</p></div> false 2009-01-29T23:06:24+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-29T23:06:28+00:00 11330 Jon Leighton Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 Thanks for your feedback Jon. Rest assured that the '_delete' and 'new_x' keys have nothing to do with any HTTP workarounds :) However, if you care to investigate an alternative API feel free to submit a patch. <div><p>Thanks for your feedback Jon.</p> <p>Rest assured that the '_delete' and 'new_x' keys have nothing to do with any HTTP workarounds :)</p> <p>However, if you care to investigate an alternative API feel free to submit a patch.</p></div> false 2009-01-30T09:50:51+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-30T09:50:54+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 Eloy, tried to apply your Jan 29th patch to the current master branch (commit ed0e5640879fd42c00fc5900e0355a0ea1dcf2ad) but it won't apply. Any chance of an updated patch - unless the commit to master is coming in the next day or so? <div><p>Eloy, tried to apply your Jan 29th patch to the current master branch (commit ed0e5640879fd42c00fc5900e0355a0ea1dcf2ad) but it won't apply. Any chance of an updated patch - unless the commit to master is coming in the next day or so?</p></div> false 2009-01-31T04:51:58+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-31T04:52:04+00:00 26903 Kip Cole Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 Created a new patch because apparently for some reason my format-patch skills fail… This is just 1 patch with all patches combined in one. Here's the commit message I compiled: Added the association accessor methods `association_instance_set' and `association_instance_get'. Replaced all code with this which was accessing the association ivars directly. See #1728. Fixed assert_queries to _not_ count BEGIN and COMMIT queries. See #1732. Added AutosaveAssociation, which is a module that takes care of automatically saving your associations when the parent is saved. In addition to saving, it also destroys any associations that were marked for destruction. Added NestedAttributes module which adds the accepts_nested_attributes_for class method. With this method an attributes writer is defined for an association. This allows you to set and update attributes of associated models through the parent model as well as destroying them. Also included are adjustments to FormBuilder#fields_for to support such nested model attributes. <div><p>Created a new patch because apparently for some reason my format-patch skills fail&#8230; This is just 1 patch with all patches combined in one. Here's the commit message I compiled:</p> <p>Added the association accessor methods <code>association_instance_set' and</code>association_instance_get'. Replaced all code with this which was accessing the association ivars directly. See <a href="/projects/8994/tickets/1728" title="Ticket #1728">#1728</a>.</p> <p>Fixed assert_queries to <em>not</em> count BEGIN and COMMIT queries. See <a href="/projects/8994/tickets/1732" title="Ticket #1732">#1732</a>.</p> <p>Added AutosaveAssociation, which is a module that takes care of automatically saving your associations when the parent is saved. In addition to saving, it also destroys any associations that were marked for destruction.</p> <p>Added NestedAttributes module which adds the accepts_nested_attributes_for class method. With this method an attributes writer is defined for an association. This allows you to set and update attributes of associated models through the parent model as well as destroying them. Also included are adjustments to FormBuilder#fields_for to support such nested model attributes.</p></div> false 2009-01-31T18:03:29+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-31T18:03:32+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 3 And the new patch. <div><p>And the new patch.</p></div> false 2009-01-31T18:03:58+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 new actionview activerecord enhancement patch 2009-01-31T18:04:04+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 4 (from [ec8f04584479aff895b0b511a7ba1e9d33f84067]) Add support for nested object forms to ActiveRecord and the helpers in ActionPack Signed-Off-By: Michael Koziarski <michael@koziarski.com> [#1202 state:committed] http://github.com/rails/rails/commit/ec8f04584479aff895b0b511a7ba1e9d33f84067 <div><p>(from [ec8f04584479aff895b0b511a7ba1e9d33f84067]) Add support for nested object forms to ActiveRecord and the helpers in ActionPack</p> <p>Signed-Off-By: Michael Koziarski <a href="mailto:michael@koziarski.com">michael@koziarski.com</a></p> <p>[<a href="/projects/8994/tickets/1202" title="Ticket #1202">#1202</a> state:committed] <a href="http://github.com/rails/rails/commit/ec8f04584479aff895b0b511a7ba1e9d33f84067"> http://github.com/rails/rails/co...</a></p></div> true 2009-02-01T02:02:21+00:00 8406 --- :state: new 1202 add-attributes-writer-method-for-an-association 0 8994 committed actionview activerecord enhancement patch 2009-02-01T02:02:24+00:00 17393 Repository Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 4 This doesn't work well when validating the relationship. For example, http://gist.github.com/82527. At least I've seen no docs on it yet (and probably haven't looked hard enough...) This is a problem when creating new objects. <div><p>This doesn't work well when validating the relationship. For example, <a href="http://gist.github.com/82527">http://gist.github.com/82527</a>. At least I've seen no docs on it yet (and probably haven't looked hard enough...)</p> <p>This is a problem when creating new objects.</p></div> true 2009-03-20T19:50:50+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 committed actionview activerecord enhancement patch 2009-03-20T19:50:55+00:00 18189 orangechicken Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 4 @orangechicken See this ticket #1943. <div><p>@orangechicken See this ticket <a href="/projects/8994/tickets/1943" title="Ticket #1943">#1943</a>.</p></div> true 2009-03-21T00:11:12+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 committed actionview activerecord enhancement patch 2009-03-21T00:11:16+00:00 8406 Eloy Duran Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 8406 4 I am using nested forms on a person model that has many pictures. I would like to allow the user to remove on or more of the associated pictures from the person using nested forms as suggested by Ryan Bates. However delete will delete the picture not remove the associatioon I can do it in the controller, but it should be done in the same way as delete is performed using attribute _delete Is there a _remove attribute or any other way to solve the problem (e.g. that a command like allow_remove=true) Another problem is that it seems as nested forms do not validate the attributes of the associated object in this case picture (the name should be unique). I have solved the problem by a fix in the controller, but shouldn't that be a feature of nested forms Any comment would be much appreciated <div><p>I am using nested forms on a person model that has many pictures.<br> I would like to allow the user to remove on or more of the associated<br> pictures from the person using nested forms as suggested by Ryan Bates.</p> <p>However delete will delete the picture not remove the associatioon<br> I can do it in the controller, but it should be done in the same way as<br> delete is performed using attribute <em>delete<br> Is there a</em> remove attribute or any other way to solve the problem<br> (e.g. that a command like allow_remove=true)</p> <p>Another problem is that it seems as nested forms do not validate the<br> attributes of the associated object in this case picture (the name should be unique).<br> I have solved the problem by a fix in the controller, but shouldn't that be a<br> feature of nested forms</p> <p>Any comment would be much appreciated</p></div> true 2009-08-02T08:42:23+01:00 8406 --- :assigned_user: 141 1202 add-attributes-writer-method-for-an-association 0 8994 committed actionview activerecord enhancement patch 2009-08-02T08:42:27+01:00 64804 Hans Eloy Duran Eloy Duran http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 4 Sorry about the change of assigned user - my mistake Have changed the code and then the validation seems to work However, the problem of removing / deleting associations is still a problem <div><p>Sorry about the change of assigned user - my mistake<br> Have changed the code and then the validation seems to work<br> However, the problem of removing / deleting associations is still a problem</p></div> true 2009-08-03T09:27:20+01:00 8406 --- :assigned_user: 8406 1202 add-attributes-writer-method-for-an-association 0 8994 committed actionview activerecord enhancement patch 2009-08-03T09:27:25+01:00 64804 Hans Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 141 4 Sorry for the term, but {"id" => 22, "_delete" => 1} is retarded. How about checking that attributes hash, and if it contains _child key_ and is set to nil, then destroy that child? That means, for has_one associations, it should be enough to pass a hash like: @@@ ruby { :author => nil } @@@ ...and for deleting in has_many: @@@ ruby { :comments => { 22 => nil, 23 => nil }} @@@ ...and for deleting, updating and creating in one go: @@@ ruby { :comments => { 22 => nil, 23 => { :title => 'twenytri' }, 0 => { :title => 'titty', :body => 'ritty' } }} @@@ However, that 0 key is obvious hack, any ideas on that? <div><p>Sorry for the term, but {"id" =&gt; 22, "<em>delete" =&gt; 1} is retarded. How about checking that attributes hash, and if it contains</em> child key_ and is set to nil, then destroy that child?</p> <p>That means, for has_one associations, it should be enough to pass a hash like:</p> <pre> <code class="ruby">{ :author =&gt; nil }</code> </pre> <p>...and for deleting in has_many:</p> <pre> <code class="ruby">{ :comments =&gt; { 22 =&gt; nil, 23 =&gt; nil }}</code> </pre> <p>...and for deleting, updating and creating in one go:</p> <pre> <code class="ruby">{ :comments =&gt; { 22 =&gt; nil, 23 =&gt; { :title =&gt; 'twenytri' }, 0 =&gt; { :title =&gt; 'titty', :body =&gt; 'ritty' } }}</code> </pre> <p>However, that 0 key is obvious hack, any ideas on that?</p></div> true 2009-12-03T14:45:23+00:00 8406 --- {} 1202 add-attributes-writer-method-for-an-association 0 8994 committed actionview activerecord enhancement patch 2009-12-03T14:45:27+00:00 22610 Dusan Maliarik Eloy Duran Michael Koziarski http://rails.lighthouseapp.com/projects/8994/tickets/1202 6d85e994539d419e87b64c105535f01a400292c6 text/plain 2008-12-17T16:05:51+00:00 nested_changes.diff 72160 3369 11785 http://rails.lighthouseapp.com/attachments/72160/nested_changes.diff 6bbc88bbce51c332a4f877be1ae72b6d0f975efc text/plain 2009-01-21T15:57:05+00:00 3.autosave_association.diff 80432 32762 8406 http://rails.lighthouseapp.com/attachments/80432/3.autosave_association.diff 1656cc415afe2eddf747365afc54978dbcc7140b text/plain 2009-01-29T08:31:33+00:00 4.nested_attributes.diff 82796 65261 8406 http://rails.lighthouseapp.com/attachments/82796/4.nested_attributes.diff c83c1fc5222bc39f5173aba37afbd560dc6843df text/plain 2009-01-31T18:03:58+00:00 association_instance_accessors_and_autosave_association_and_nested_attributes.diff 83579 85906 8406 http://rails.lighthouseapp.com/attachments/83579/association_instance_accessors_and_autosave_association_and_nested_attributes.diff