On Sep 17, 2008, at 2:13 AM, Eloy Duran wrote:
>> 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.
>
> I really can't think of a common use case for this scenario.
> It seems to me that when you're paginating a form, or any other edge
> case,
> you shouldn't rely on any naive solution, but rather solve it yourself
> in your controller/model.
>
> This is why I personally feel that destroying a record should be off
> by default.
>
> But for simple common use cases, where you might have removed
> a child from the DOM, the naive/simple approach I took in my plugin is
> good enough IMO.
This isn't a naive solution, but one that worked well for us in a
rather complicated workflow. Making the controller do extra stuff to
handle deletes outside of the save transaction is annoying and
problematic. Letting the model handle deletes as part of the same
operation means the entire change can be handled in one transaction,
which simplifies things a lot. We found that using a _delete field
worked best for us. Noticing that all fields were blank was a lot of
work for both the user and our code, and didn't work at all if the
model included radio buttons or select boxes without the blank option.
>>> 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.
>
> This is a very valid point which I have fixed in:
> http://github.com/alloy/complex-form-examples/commit/4c740d5d8f5f99c0bfa5c3f38162ef26329c7cf0
> Thanks for bringing that up.
>>> 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.
>
> I'm sorry, but my English is not good enough to follow this bit.
> Could you maybe explain it some more or in other words?
Sorry about that, I was using non-standard jargon. I use "faux
accessor" to describe a model method that pretends to be an attribute
accessor for the purpose of using a form to edit something that isn't
a primitive attribute. And in my proposed patch for parameterized
associations I use two different faux accessors for the API, e.g.
create_tasks_params and update_tasks_params.
--
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
-~----------~----~----~----~------~----~------~--~---
