Greetings Jacon and Ed, As Rafael already mentioned, there is an ongoing process to support Form Models/Objects. There is a Rails plugin(https://github.com/rails/activeform) in early stage. Me and Carlos worked on it during the GSoC period.
We would appreciate it if you had a look at it and give us any feedback on how it supports your current needs. We would benefit a lot if we could find some real-world needs. Looking forward to hearing from you, Peter Markou Τη Πέμπτη, 11 Σεπτεμβρίου 2014 5:35:20 μ.μ. UTC+3, ο χρήστης Jacobo Blasco έγραψε: > > 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.
