Cool, Dave, nice approach. I added it to the gist. http://gist.github.com/10793
Out of curiosity, do you have a "new task" link on the form which dynamically adds new fields using Javascript? Is it difficult to generate the auto-incrementing number with this? Regards, Ryan On Sep 16, 8:01 am, Dave Rothlisberger <[EMAIL PROTECTED]> wrote: > For what it's worth, in my project I've been using something like a > combination of Approaches 1 & 3 (fromhttp://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 -~----------~----~----~----~------~----~------~--~---
