>> 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.
I was referring to my implementation as being naive, not yours :) > 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. Indeed I would solve this in the model as well. I still don't see the pagination etc as a common use case. However, adding the option to check for the presence of "_delete" => "1", seems an easy/clear enough option as well. > 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. Just to be sure that we are talking about the same, and not different approaches from the gist :) My implementation has 2 distinct options; - :reject_empty : Which doesn't create new records for empty hashes. - :destroy_missing : Which destroys records if they're missing in the attributes hash. Both of these are off by default. > 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. Thanks for the clarification. I agree. As I always prefer comparing implementation over discussion, I will take some time one of the next few days to turn my plugin into a patch. I will also include the option to mark a record to be destroyed with "_delete". Eloy --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
