The DELETE on /items/1/delete would only be for convenience to gracefully degrade with javascript. The DELETE on /items/1 should definitely stay.
Regards,
Ryan
I strongly agree with Josh on this one. Scaffolds should generate the minimum necessary to get things working in the most common case. When you generate scaffolds you're not writing tests, you're not thinking about exact requirements, it's just a proof of concept to get off the ground. Anything beyond the absolute basics should be something you write yourself.
I strongly agree with Josh on this one. Scaffolds should generate the minimum necessary to get things working in the most common case. When you generate scaffolds you're not writing tests, you're not thinking about exact requirements, it's just a proof of concept to get off the ground. Anything beyond the absolute basics should be something you write yourself.
As do I.
Guys, the goal for scaffolding is to give new-developers a decent intro into how to wire up a web application in rails. it is *not* intended to be used for production / shipping code. It's an education tool, not a development tool.
Now before you come back and say "I use it in production!" that's great, and so do I, but that's not it's primary goal.
We have several alternative scaffolding plugins which would be the right place to have this functionality, the scaffolding in core doesn't need anything else.
Thank you Yehuda. And because I feel strongly about this, I've made a patch (which apparently is already marked 'wont fix') at https://rails.lighthouseapp.com/projects/8994/tickets/3029-patch-non-javascript-dependent-record-deletion-solution It's got documentation, code, and test changes.
It's not hard to see why this is needed. Very simply, you can't delete a record with Javascript disabled, and that is very bad!
However, I am also in support of the other solution mentioned in this thread, of an inline form, with javascript confirmation as well, that degrades. Some very simple styling, and the Delete button could be made to look like a link. However, it still means users with Javascript disabled could mistakenly click delete and its gone. So I'd still prefer the delete action solution, because, as Chris said so well, "some resources are too important to delete without confirmation".
And as a reminder:
"It makes poor and slow UI. " - Pratik
No, it's not. Users with Javascript on still get the Javascript prompt, and when accepted, goes right ahead and hits the destroy action (they don't need to look at the delete action). This case only handles where Javascript is disabled.
"the scaffolding in core doesn't need anything else." - Michael
But the core problem behind this change would still be present without changes.
And it's not a lot of scaffolding changes. It's one existing line change, 3 new controller lines, and one small view file.
The rest of the code happens in tests/routing to allow the delete_users_path(user) resources without having to add it to each resource in routes.
It's not a big ask considering some of the other scaffold changes that have been proposed in another thread (support for _form partial, changing all HTML markup).
Regards Kieran
FWIW,
I implement my delete actions by using a modified version of button_to which actually creates an inline form with a *button* tag instead of an input of type 'submit'
That way, I can style the button to appear exactly like a link. I can also attach the appropriate javascript to the form (instead of the button) to display the confirmation dialog and cancel the submit if necessary.
Like Nicolás, I am giving my +1 to actually changing submit_tag and button_to to a button tag and possibly upgrading the scaffold code to use button_to for delete actions.
-christos