Using the presence of the :id attribute to distinguish old vs new records seems ok, but it might get wonky for edge cases that use a different primary key. I think I do like that approach. The thing that is important that some of the gisted approaches miss is being able to order new records in the form. It can get seriously confusing for users if data shifts around form one place to another if they failed a validation and need to correct something.
I'm not particularly attached to using two different faux accessors for create vs update. It's nice and clean, but really any way that lets you tell create vs update is fine by me. --josh On Sep 16, 2008, at 11:27 AM, Ryan Bates wrote: > > 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. > > -- Josh Susser http://blog.hasmanythrough.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
