For what it's worth, in my project I've been using something like a
combination of Approaches 1 & 3 (from http://gist.github.com/10793):
{
tasks =>
{
'1' => { :id => '3', :name => 'Foo' },
'2' => { :name => 'Bar' },
'3' => { :name => 'Baz' },
}
}
As with Approach 1, you can tell new records from existing records by
the lack of an :id attribute.
As with Approach 3, this supports nesting associations multiple levels
deep because it uses a hash rather than arrays.
The keys in the tasks array (1, 2 & 3) come from the counter variable
created by render :partial, :collection (or from an each_with_index
loop).
Regards
Dave.
On Sep 15, 4:43 pm, Ryan Bates <[EMAIL PROTECTED]> wrote:
> I've been giving some thought to the interface. One question I keep
> coming back to is: how much do we want to support multi-model forms
> through this? I think that is the primary use case, but this has other
> uses as well. Active Record is not specific to web interfaces and
> therefore shouldn't be tied too heavily to them.
>
> IMO Approach 1 (athttp://gist.github.com/10793) is the cleanest
> approach if we're just doing this all in Ruby. This is also fairly
> easy to use in a web form. However, there are a few major drawbacks
> when doing so:
>
> 1. The resulting HTML is not validatable due to the duplicate form
> field names.
> 2. It's more difficult to work with the fields in Javascript because
> of the duplicate form field names.
> 3. It's impossible to nest associations multiple layers deep because
> it gets confused when there are multiple "[]" in the field name.
> 4. Checkboxes (and I think radio buttons?) are nearly impossible to
> get working.
>
> Each of these problems stem from the fact that not each field has a
> unique name/identifier. Therefore when it comes to multi-model form
> fields, I'm more inclined to go with Approach 3 because each record
> has its own unique key/identifier. Theoretically that will solve all
> of the problems above.
>
> That said, if you ever need to set associated attributes in other
> scenarios (maybe preparing data in test cases), then Approach 3 is not
> clean or optimal.
--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
