Sorry I'm late to this discussion, I've been on holidays. I've already spammed the list with this before, but I believe my plugin (which screws with UrlEncodedParameterParser) could solve some of the issues you guys are running into with this.
http://www.vector-seven.com/git/rails/plugins/form_collections.git/ It's not very well named, but it effectively uses Arrays instead of Hashes when numeric indices are used in the form. It also simplifies the implementation of UrlEncodedPairParser at the expense of slightly modified semantics in the parameter parsing (i.e. yes, it breaks a few tests -- some of which I'm convinced were not correct to begin with). With such a patch in play, ordering issues would be resolved (thanks to the use of Arrays) and updates could be detected by effectively checking if the :id attribute is set on the nested form attributes. In the "Add Comment" case mentioned later in this discussion, I would assume one would be doing a many_assoc#<< rather than a many_assoc#= ... The only thing really missing from the plugin is a way to handle sparse arrays. i.e. Assigning values only to indices 1, 200 and 999 of an array should not yield an array of 1000 elements, 997 of which are nil. This should be fairly trivial. Cheers, Tom Ryan Bates 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 (at http://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 -~----------~----~----~----~------~----~------~--~---
