:+1: Carlos may have more input about this one but I think it is a good change since we are planning to support form objects/
Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Thu, Sep 11, 2014 at 11:35 AM, Jacobo Blasco <jac...@casecommons.org> wrote: > Hello, > > We posted this message in GitHub a few weeks ago ( > https://github.com/rails/rails/issues/16516), and Rafael Franca gently > pointed us at this mailing list. He suggested that we open up the > discussion to see if this feature request would be accepted or not. All > suggestions are welcomed - especially regarding the implementation. > > We have various :has_many associations in our application, but we want to > move away from *accepts_nested_attributes* due to an increasingly large > and complex domain and workflow model. We want more control over how model > attributes get updated and are willing to forfeit the convenience of > accepts_nested_attributes. Unfortunately, the *FormBuilder#fields_for* > method doesn't play well with this design decision. As per the > documentation, it requires the parent model to respond to > *"#{association}_attributes="*. This seems unnecessarily restrictive. > > In the example provided by the documentation ( > http://api.rubyonrails.org/classes/ActionView/Helpers/FormBuilder.html#method-i-fields_for > ): > > class Person > def projects > [@project1, @project2] > end > > def projects_attributes=(attributes) > # Process the attributes hash > end > end > > It would be possible to just inspect *projects* to realize that it is a > collection and treat it the same as nested attributes. The following > snippet contains a one line change that appears to accomplish this (see > SUGGESTED CODE, extracted from *lib/action_view/helpers/form_helper.rb*): > > def fields_for(record_name, record_object = nil, fields_options = {}, &block) > fields_options, record_object = record_object, nil if > record_object.is_a?(Hash) && record_object.extractable_options? > fields_options[:builder] ||= options[:builder] > fields_options[:namespace] = options[:namespace] > fields_options[:parent_builder] = self > case record_name > when String, Symbol > # ORIGINAL CODE > # if nested_attributes_association?(record_name) > # END OF ORIGINAL CODE > > # SUGGESTED CODE > if nested_attributes_association?(record_name) *|| > record_object.respond_to?(:to_ary)* > # END OF SUGGESTED CODE > return fields_for_with_nested_attributes(record_name, record_object, > fields_options, block) > end > else > record_object = record_name.is_a?(Array) ? record_name.last : record_name > record_name = model_name_from_record_or_class(record_object).param_key > end > #... > > The suggested modification would yield a more flexible solution without > coupling so tightly to nested attributes. What do you think of the idea > and of this specific solution? Rafael noted that this could break existing > applications, but we fail to see under what scenarios that would happen. > Thoughts? > > Thank You. > > Jacobo & Ed > Case Commons > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
