Feature request #1587: Show confirmation page for "destroy" buttons when JavaScript disabled

Ticket #1585 was about fixing the broken "destroy" buttons under Rails 3.

I first set up unobtrusive JavaScript, which worked, but the button (actually link) had no effect when JavaScript was disabled; it just took the user to the issues#show action.

This is not a new thing, as Rails has always degraded in that way when JavaScript is not enabled.

So I swapped in button_to for link_to, thus making the button work even without JavaScript, but we still don't get a confirmation.

Hence the purpose of this ticket: to set up an intermediate confirmation page which is shown only when JavaScript is turned off.

My first attempt was to add a special GET route for /issues/:id/destroy, which would hit the existing issues#destroy action. I could then distinguish between JavaScript and non-JavaScript requests (eg. JavaScript requests would be POST requests and non-JavaScript requests would be GET requests, and have the trailing destroy component in the URL too).

Alas, it appears I can't do that with the router. eg. given:

resources :issues do
  get :destroy, :on => :member
  get :delete, :on => :member
end

The :destroy line has no effect. Evidently the "destroy" action set up as one of the default RESTful actions takes precedence.

The :delete line, does work, but it doesn't give us what we want (it would add an entirely new action to our controllers).

The alternative would be to do the following:

• use a standard button_to link
• via JavaScript, add a hidden field indicating that JavaScript was involved in the submission
• in issues#destroy:
  • if the field is present, continue as normal
  • if it is not present, we know we got here without JavaScript enabled and the user didn't see the confirmation dialog, so we render the confirmation template, which itself includes a form with the confirmation flag already embedded in it

The question, really is, which one of these is the bigger kludge?

Is the lesser evil having an additional controller action, or having an additional hidden field?

I must admit that at first glance, the additional controller action seems the simpler and therefore more attractive option. But the pattern will need to be repeated for every model that has a "destroy" action.

So going to let it simmer here in the tracker for a while, while I decide what to do.