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
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
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".