Ryan,
> 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?
I do have a "new task" link but it doesn't use javascript (I'm
somewhat new to web development so I'm keeping this as simple as
possible, which means no javascript).
Eloy's idea of using a timestamp for the id is, as you said, genius.
Re. Josh's comment on ordering, as long as you use a hash you're safe,
right? You can order by the hash key -- I'm not missing anything?
(perhaps around javascript drag-and-drop reordering?)
Re. approach 5 (in the gist), I prefer approach 4 because in your view
you can say:
fields_for "tasks[#{position}]"
instead of having to remember "update_tasks_params[]" and
"create_tasks_params[]".
Like Eloy's implementation, in my project I specify whether or not I
want to destroy records that are missing from the hash, by
a :destroy_missing option on the has_many declaration. But I
definitely agree that the best implementation would be to match what
ActiveRecord already does for tasks= when taking an array of objects
rather than a params hash -- which is, according to the docs:
"Replaces the collection's content by deleting and adding objects as
appropriate."
Re. Eloy's :reject_empty option: I never create records if all the
attributes are blank (i.e. the user presses the "add another task"
button but leaves the task completely blank). Is there really a use
case for that? In fact, if a user deletes all the content from the
fields of an existing task, my implementation would delete that
record.
Cheers
Dave.
>
> 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
-~----------~----~----~----~------~----~------~--~---
