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 (ActionView::Helpers::FormBuilder):
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
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
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 έγραψε:
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
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
Hello, I don’t want to be in competition with Peter but I created
another similar gem : .
Both are very similar and I don’t know if there is an advantage to
use one or the other. Please, can you do a quick comparison. I just
want to learn of my errors and have good and constructive comments.