Originally replied from my inbox but for reasons unknown it didn't post to the group Apologies if this post is redundant...
Hi Peter, I'm glad our suggestion is being well received. We think it's a modest change with a nice payoff. The ActiveForm gem seems interesting and it may serve as an alternative to Presenters which is the closest thing we have in our stack to what the gem provides out of the box. Our original motive for deemphasizing out dependence on nested attributes actually comes from our current experiments moving business logic to PORO objects which for lack of a better name we're referring to "Use Case Runners." We're seeking to make what happens for a given business operation less opaque and experimenting with lessening our dependence on nested attributes and callbacks among other things. Part of what's driving that besides the sheer size and complexity of our application is the desire to maintain our software as a COTS application that has to address the needs of multiple clients with diverse business rules and workflows sometimes due to regulatory and legislative requirements. ActiveForm's scope doesn't directly address our current needs or addresses our original motivation for starting this thread. But, it could serve as an option for how we currently bind data to our views. I think it's a good thing and am glad you're tackling this space. FWIW, the above opinions are my own. I haven't compared notes with Jacobo, so he may offer another point of view. Thanks, Ed Chaparro On Tuesday, September 16, 2014 4:47:02 PM UTC-4, Peter Markou wrote: > 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.
