Hello, I don't want to be in competition with Peter but I created
another similar gem : https://github.com/GCorbel/activeform-rails. 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.
Le 2014-09-21 16:13, Ed Chaparro a écrit :
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
<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
<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
<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
<mailto:rubyonrails-core+unsubscr...@googlegroups.com>.
To post to this group, send email to rubyonrails-core@googlegroups.com
<mailto: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.
