# Non JavaScript dependent scaffolding solution for record deletion **URL:** \ **Category:** rubyonrails-core\ **Created:** [August 10, 2009, 12:20am UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989 "2009-08-10T00:20:34Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Kieran1](https://avatars.discourse-cdn.com/v4/letter/k/46a35a/32.png) [@Kieran1](https://discuss.rubyonrails.org/u/Kieran1)\ **Post date:** [August 10, 2009, 12:20am UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/1 "2009-08-10T00:20:34Z")
Hello, The generated scaffold relies on Javascript enabled to be able to delete a record, which prevents anyone with JavasScript disabled to delete it. I've hacked a solution with a delete action in one of my projects, which works nicely, and cleanly. Basically, the link still have Javascript which will work if enabled, but the url of the link goes to a delete action, with a form that confirms the user wants to delete (instead of a Javascript prompt). Only took 3 new controller lines, 6 new view lines, 1 changed view line, and a route :member. Is this something that people would like to see in Rails 3? Regards Kieran ---
**Author:** ![Josh\_Susser](https://avatars.discourse-cdn.com/v4/letter/j/90ced4/32.png) [@Josh\_Susser](https://discuss.rubyonrails.org/u/Josh_Susser)\ **Post date:** [August 10, 2009, 12:35am UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/2 "2009-08-10T00:35:24Z")
I'd vote NO. Scaffolding isn't about providing a cross-browser solution with graceful degradation. It's about giving you a temporary structure you can lean your app against while building it. By the time you want to launch the app, scaffolding should be replaced by code you built yourself. I don't have anything against doing things the way you propose, but I'd rather scaffolding stay as minimal and simple as possible. Every line of code in the scaffolding bears a maintenance cost, and it seems better to keep it easy to upgrade than make it feature-complete for end-users. ---
**Author:** ![Kieran1](https://avatars.discourse-cdn.com/v4/letter/k/46a35a/32.png) [@Kieran1](https://discuss.rubyonrails.org/u/Kieran1)\ **Post date:** [August 10, 2009, 4:09am UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/3 "2009-08-10T04:09:17Z")
Hey Josh. Thanks for your comments. > I'd vote NO. Scaffolding isn't about providing a cross-browser solution with graceful degradation. Perhaps not, but isn't it better to have applications that do and to promote graceful degredation? And even if the scaffolding doesn't get changed, the code to support a delete action by default would still be a good thing, rather than adding a collection to each resources route. > It's about giving you a temporary structure you can lean your app against while building it. Most of my code still uses scaffolded controller code (only added lines to it, didn't take away). > By the time you want to launch the app, scaffolding should be replaced by code you built yourself. For the views and tests, sure. But the base of the model and controllers likely stay the whole way through app development (at least, this has been the case with a project I'm working on at the moment). > I don't have anything against doing things the way you propose, but I'd rather scaffolding stay as minimal and simple as possible. When it comes down to it, it's only 3 controller lines and a view file. > Every line of code in the scaffolding bears a maintenance cost Shouldn't be much though right? How often does the scaffolding code change per release since 2.1? Regards Kieran ---
**Author:** ![MatthewRudy](https://avatars.discourse-cdn.com/v4/letter/m/b5a626/32.png) [@MatthewRudy](https://discuss.rubyonrails.org/u/MatthewRudy)\ **Post date:** [August 10, 2009, 9:33am UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/4 "2009-08-10T09:33:42Z")
I think this is something that is always annoying. Namely I have to reinvent a convention to handle this. Something like "pre\_delete" with a GET - this is just a proper delete form and "delete" with a DELETE - this does the delete but I think we deserve to have this baked into rails. I think it'd be cool if; GET /posts/delete mapped to the "pre-delete" action DELETE /posts/delete mapped to the "delete action" thereby, with a "link\_to "delete", :method =\> :delete" you automatically fall back when javascript is disabled. Boom. ---
**Author:** ![Yehuda\_Katz](https://avatars.discourse-cdn.com/v4/letter/y/f14d63/32.png) [@Yehuda\_Katz](https://discuss.rubyonrails.org/u/Yehuda_Katz)\ **Post date:** [August 10, 2009, 11:39am UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/5 "2009-08-10T11:39:26Z")
I am in favor of a standard delete action, analagous to new and edit. I can’t think of a good reason not to have it–it shows good practice and isn’t exactly a new concept. We have new and edit as HTML precursor actions for the POST and PUT verbs, why not delete as HTML precursor for DELETE. One of the biggest wins of Rails is conventionality; when you come into a new Rails app, you don’t have to wonder what the edit action is called. Why not extend this to delete confirmation screens as well? – Yehuda MatthewRudy wrote: ---
**Author:** ![Yehuda\_Katz](https://avatars.discourse-cdn.com/v4/letter/y/f14d63/32.png) [@Yehuda\_Katz](https://discuss.rubyonrails.org/u/Yehuda_Katz)\ **Post date:** [August 10, 2009, 11:43am UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/6 "2009-08-10T11:43:28Z")
MatthewRudy wrote: > ```ruby > > I think this is something that is always annoying. > Namely I have to reinvent a convention to handle this. > Something like "pre_delete" with a GET > - this is just a proper delete form > and "delete" with a DELETE > - this does the delete > but I think we deserve to have this baked into rails. > I think it'd be cool if; > GET /posts/delete mapped to the "pre-delete" action > DELETE /posts/delete mapped to the "delete action" > > ``` This doesn’t make sense. The normal HTTP convention would be: DELETE /posts/1 to delete. I like the idea of: GET /posts/1/delete for a DELETE confirmation screen. You’d then have: ---
**Author:** ![Pratik1](https://avatars.discourse-cdn.com/v4/letter/p/6bbea6/32.png) [@Pratik1](https://discuss.rubyonrails.org/u/Pratik1)\ **Post date:** [August 10, 2009, 11:51am UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/7 "2009-08-10T11:51:25Z")
-1. > I am in favor of a standard delete action, analagous to new and edit. I can't think of a good reason not to have it--it shows good practice and isn't exactly a new concept. It makes poor and slow UI. > We have new and edit as HTML precursor actions for the POST and PUT verbs, why not delete as HTML precursor for DELETE. One of the biggest wins of Rails is conventionality; when you come into a new Rails app, you don't have to wonder what the edit action is called. Why not extend this to delete confirmation screens as well? When you edit/create - you don't just press one button. You enter a good amount of data too. That's not true when you DELETE the record in 99.99% of the cases. ---
**Author:** ![Yehuda\_Katz](https://avatars.discourse-cdn.com/v4/letter/y/f14d63/32.png) [@Yehuda\_Katz](https://discuss.rubyonrails.org/u/Yehuda_Katz)\ **Post date:** [August 10, 2009, 11:58am UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/8 "2009-08-10T11:58:16Z")
Pratik wrote: > ```ruby > -1. > > ``` +2 > ```ruby > > ``` > > > ```ruby > > I am in favor of a standard delete action, analagous to new and edit. I > > can't think of a good reason not to have it--it shows good practice and > > isn't exactly a new concept. > > > > ``` > > ```ruby > It makes poor and slow UI. > > ``` Sure. Better than no UI, wouldn’t you say? > > ```ruby > > We have new and edit as HTML precursor actions > > for the POST and PUT verbs, why not delete as HTML precursor for DELETE. One > > of the biggest wins of Rails is conventionality; when you come into a new > > Rails app, you don't have to wonder what the edit action is called. Why not > > extend this to delete confirmation screens as well? > > > > ``` > > ```ruby > When you edit/create - you don't just press one button. You enter a > good amount of data too. That's not true when you DELETE the record in > 99.99% of the cases. > > ``` Are you suggesting that we just put an inline small form with a submit button to DELETE the record? I’d be ok with that, provided we’re not worried about the lack of confirmation. Maybe gracefully degrading the confirmation isn’t very important (after all, the functionality is still available)? – Yehuda ---
**Author:** ![Luke\_Melia](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/luke_melia/32/11548_2.png) [@Luke\_Melia](https://discuss.rubyonrails.org/u/Luke_Melia)\ **Post date:** [August 10, 2009, 12:18pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/9 "2009-08-10T12:18:20Z")
+1 We follow this pattern and I've often wished it was a standard resource action instead of cluttering up my routes file. To the UI concern, we enhance the links via javascript to do an immediate destroy where appropriate (just takes one attribute on the link once you have a little app-wide JS in place). It makes testing with cucumber/webrat easier and gives us a built-in solution for users without javascript. ---
**Author:** ![Mislav](https://avatars.discourse-cdn.com/v4/letter/m/77aa72/32.png) [@Mislav](https://discuss.rubyonrails.org/u/Mislav)\ **Post date:** [August 10, 2009, 12:37pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/10 "2009-08-10T12:37:48Z")
I was just about to suggest that when I read the rest of the comments. +1 for the inline form ---
**Author:** ![Chris2](https://avatars.discourse-cdn.com/v4/letter/c/ac8455/32.png) [@Chris2](https://discuss.rubyonrails.org/u/Chris2)\ **Post date:** [August 10, 2009, 1:36pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/11 "2009-08-10T13:36:32Z")
I like the idea of a small inline form for scaffolding. But I also REALLY like the idea of a standard HTML-only approach that supports confirmation: some resources are too important to delete without confirmation (or better yet, a "review" of the consequences), and counting on JavaScript is Bad. +1 for GET /posts/1/delete +1 for small inline form in scaffolding that DELETE /posts/1 (without confirmation if deemed appropriate). -Chris ---
**Author:** ![Mateo\_Murphy](https://avatars.discourse-cdn.com/v4/letter/m/ec9cab/32.png) [@Mateo\_Murphy](https://discuss.rubyonrails.org/u/Mateo_Murphy)\ **Post date:** [August 10, 2009, 1:42pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/12 "2009-08-10T13:42:09Z")
I I agree that for the purposes of scaffolding, it should be an inline form. However, I think having map.resource(s) support GET /posts/1/delete by default would be a good idea; often a javascript popup isn't the best way to ask for confirmation ---
**Author:** ![Alexander\_Wallace](https://avatars.discourse-cdn.com/v4/letter/a/d9b06d/32.png) [@Alexander\_Wallace](https://discuss.rubyonrails.org/u/Alexander_Wallace)\ **Post date:** [August 10, 2009, 1:42pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/13 "2009-08-10T13:42:58Z")
Toss in another favorable vote for an inline form with a submit for the DELETE action. This would be good as it (a) gracefully degrades on its own, and (b) clearly illustrates to the developer what code needs to be written to put the form together correctly in the future. I view the confirmation alert as a “nice-to-have” feature but not necessary to the base scaffolding functionality. Perhaps that would be a reasonable case for inline javascript on the deletion form? Just enough to make it work out of the box and demonstrate what should be going on. -Alex ---
**Author:** ![Pratik1](https://avatars.discourse-cdn.com/v4/letter/p/6bbea6/32.png) [@Pratik1](https://discuss.rubyonrails.org/u/Pratik1)\ **Post date:** [August 10, 2009, 1:44pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/14 "2009-08-10T13:44:55Z")
> +2 [Dissociative identity disorder - Wikipedia](http://en.wikipedia.org/wiki/Dissociative_identity_disorder) ?? You're just one person, wake up 😉 > Are you suggesting that we just put an inline small form with a submit button to DELETE the record? I'd be ok with that, provided we're not worried about the \> lack of confirmation. Maybe gracefully degrading the confirmation isn't very important (after all, the functionality is still available)? No I'm not suggesting that. I'm not suggesting any change. You are. And confirmation \*is\* important. I understand the change you people are suggesting is desired in many situations. However, it's very easy to add that and it does not belong in scaffolding. ---
**Author:** ![Allen3](https://avatars.discourse-cdn.com/v4/letter/a/7ba0ec/32.png) [@Allen3](https://discuss.rubyonrails.org/u/Allen3)\ **Post date:** [August 10, 2009, 1:47pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/15 "2009-08-10T13:47:10Z")
I like the delete GET for a confirmation page. However, if javascript is enabled it should allow the bypass of this page. ---
**Author:** ![Nicolas\_Sanguinetti](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/nicolas_sanguinetti/32/8867_2.png) [@Nicolas\_Sanguinetti](https://discuss.rubyonrails.org/u/Nicolas_Sanguinetti)\ **Post date:** [August 10, 2009, 2:32pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/16 "2009-08-10T14:32:47Z")
+1 for using button\_to instead of link\_to. And if submit\_tag were to generate a \ instead of an \ then +10000000000 🙂 -foca ---
**Author:** ![Jason\_King1](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@Jason\_King1](https://discuss.rubyonrails.org/u/Jason_King1)\ **Post date:** [August 10, 2009, 3:38pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/17 "2009-08-10T15:38:25Z")
Not sure I understand your position. The existing functionality where a JS dialogue appears requires the user to just press one button, and you’re saying that this is good UI, but having an HTML form appear requiring the user to press a button is not good UI? Seems like precisely the same UI to me, just in two different forms and with the obvious latency for the non-JS user. As others have mentioned, surely a slower UI is better than no UI at all? ---
**Author:** ![rbates](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/rbates/32/4514_2.png) [@rbates](https://discuss.rubyonrails.org/u/rbates)\ **Post date:** [August 10, 2009, 6:58pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/18 "2009-08-10T18:58:53Z")
+1 for the GET request on a delete action to show a confirmation dialog. Also if you send a DELETE call to this URL it could trigger the destroy action directly. This way it conveniently degrades nicely with javascript. \<%= link\_to "Destroy", delete\_item\_path(item), :method =\> :delete, :confirm =\> "Are you sure?" %\> GET /items/1/delete # =\> maps to delete action with confirmation screen DELETE /items/1/delete # =\> maps to destroy action If javascript is disabled it will fall back to a GET request and therefore display a confirmation screen. Having this defined by default in map.resources would be convenient and won't get in the way if not used. Whether or not scaffolding takes advantage of this I don't care. Ryan ---
**Author:** ![Jason\_King1](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@Jason\_King1](https://discuss.rubyonrails.org/u/Jason_King1)\ **Post date:** [August 10, 2009, 7:17pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/19 "2009-08-10T19:17:10Z")
> +1 for the GET request on a delete action to show a confirmation dialog. Also if you send a DELETE call to this URL it could trigger the destroy action directly. This way it conveniently degrades nicely with javascript. > > \<%= link\_to "Destroy", delete\_item\_path(item), :method =\> :delete, :confirm =\> "Are you sure?" %\> > > GET /items/1/delete # =\> maps to delete action with confirmation screen DELETE /items/1/delete # =\> maps to destroy action > > If javascript is disabled it will fall back to a GET request and therefore display a confirmation screen. That's very tidy, +1 on that specific permutation. I presume the idea would be to have DELETE /items/1 still mapping to destroy as well, for backwards compat (with a deprecation notice). If not - then -1 🙂 > Having this defined by default in map.resources would be convenient and won't get in the way if not used. Whether or not scaffolding takes advantage of this I don't care. I think if you make it like this then you need to have scaffolding support it - otherwise (I think) you'll get a missing template error when JS is disabled, which is untidy -\> "Won't somebody PLEASE think of the newbs?!?" +1 for scaffolding support. Cheers, Jason ---
**Author:** ![Matt\_Jones](https://avatars.discourse-cdn.com/v4/letter/m/258eb7/32.png) [@Matt\_Jones](https://discuss.rubyonrails.org/u/Matt_Jones)\ **Post date:** [August 10, 2009, 7:31pm UTC](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989/20 "2009-08-10T19:31:17Z")
I'd certainly hope there's not a deprecation notice - the 'DELETE /items/1/delete' is distinctly un-RESTful. The HTTP verb is sufficient - do we really want to be POSTing to /items/create and PUTting to /items/1/update (again)? --Matt Jones [Next page](https://discuss.rubyonrails.org/t/non-javascript-dependent-scaffolding-solution-for-record-deletion/44989.md?page=2)