The main concern that I have seen presented is that form injection
could cause data to be created/updated around your database
that you did not intend should the attacker carefully craft a form for
It'd be a great idea to go through the requirements you cover in your
awesome screencasts, and see how this helps or hinders each case.
That'd help us get a handle on how this is going to play out.
> Good point David, this can be very dangerous if always enabled due to
> form injection. But when intentionally enabled, this has the potential
> to greatly simplify multi-model forms - which I love!
> Out of curiosity, have you tried making a multi-model form with this?
> I can if you want. There are a lot of complexities involved,
> specifically with regards to when the associated models are saved and
> what happens when validation fails.
Yep, exactly. I talked with David Dollar on IRC about this. I've
done this in a way that is similar to your recipe in ARR, but I create/
update the associated models in a before_validation callback, rather
than in the setter. That keeps everything in one transaction and
makes it a little easier to handle validation issues. I did like your
approach of splitting the setters into two pieces for create and
update. The one thing that keeps bugging me though is doing deletes -
I've still yet to figure out a really nice way to handle that.
p = Project.find(:first)
p.tasks.first.name = 'New Name'
does not update the Task in the database. I'd like to get some
thoughts/opinions on using dirty tracking to make cascadable saves
If I could cascade the saves, it becomes a lot easier to bubble up
validations in a format that makes sense for nested associations.
> You received this message because you are subscribed to the Google
> Groups "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonra...@googlegroups.com
> To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
> On a related-yet-slightly-different-topic note:
> p = Project.find(:first)
> p.tasks.first.name = 'New Name'
> does not update the Task in the database. I'd like to get some
> thoughts/opinions on using dirty tracking to make cascadable saves
> If I could cascade the saves, it becomes a lot easier to bubble up
> validations in a format that makes sense for nested associations.
Whoa pardner, that's dangerously close to the Unit-of-Work pattern
there! I like this idea (it's been discussed before many times), but
it's a huge change to how things work. Much moreso than just partial
updates. I'm all for it though.
The big issue I see is finding the associated objects that need
saving. AR isn't good at dealing with partially loaded has_many
association collections. I think you'd need a new API on associations
to enumerate the already loaded records and see which are dirty and
p = Project.find(some_id)
task = p.tasks.find_by_name("send invoice")
task.due_date = 3.days.from_now
There's a lot that would need to happen to make that example work, and
maybe that's even reaching a bit too far. Anyway, just thinking out
Bit late to the party I know, but can't you just do:
<% form_for :product do |product| %>
<%= product.text_field :name %>
<% product.fields_for :price do |price| %>
<%= price.text_field :quantity %>
<% end %>
<% end %>
I hope you can, because I've been using it in apps for ages!
Thanks to the great suggestions both here and in #rails-contrib, I'm
on a slightly different angle to this patch. Hopefully I'll have the
in another day or two to post up here for review, but hopefully I can
the many legitimate concerns that have been raised.
Since I haven't really seen much outside of your response and Koz's, I
assumed that either nobody has any feedback or nobody has really run
into this problem and so doesn't particularly care. I find both hard to
believe -- I know how opinionated the ruby community can get ;).
I understand it's a subtle change, but I would have thought the scenario
you just described is relatively common. I know we've run into it more
than once, and it was the reason the plugin came about in the first place.
In any case, thanks for putting in your two cents.
In fact I find that the initial checkin
(e0750d6a5c7f621e4ca12205137c0b135cab444a) works quite well.
I've swapped out a few custom association_attributes= style sections
(ala Ryan Bates complex forms style) for the new accessible => true
support and it really seems to work great - even with updates and
What about has_many associations to models containing more than one field?
class Student < ...
# has a name, age, year_level
class School < ...
The main concern I have is the obvious backwards compatibility and
security issues which were covered in that email. We have an,
allegedly, pluggable parameter parsing scheme. It should be possible
to plug this behaviour in without using a patch? At least that'd let
us test the implications of making the changes.