Oh yeah, I should add a refinement of "Approach 4":
{
:tasks_params =>
{
'1' => { :id => '3', :name => 'Foo' },
'2' => { :id => '17', :_delete => '1', :name => 'Bob' },
'3' => { :name => 'Bar' },
'4' => { :name => 'Baz' }
}
}
The presence of a :_delete param is used to indicate that an old
record should be deleted. This can be done simply with a checkbox or
a JavaScript control. I think this works much better than trying to
delete records that just happen to be missing from the hash, since
that can get ugly if you are paginating a bunch of records or
otherwise subsetting e the list.
And I do think the _params (or _attributes) suffix on the name is
important.
Anyway, I'll try and get my proposed patch mashed around for this new
arrangement, and see if we can get a good form_for mod to support this
as well.
--josh
On Sep 16, 2008, at 12:12 PM, Josh Susser wrote:
>
> 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
>
>
>
> >
--
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
-~----------~----~----~----~------~----~------~--~---
