Confirmation Dialog

part of the ArsDigita Community System by Lars Pind on June 5, 2000.

The Big Picture

Several places in the ACS, we have a confirmation page: "Are you sure you want to nuke this user?". It's a waste of time to write such pages over and over again. Furthermore, if you decide that you prefer javascript or some other fancy feature over simple redirects, you have to edit many different places. Thus, there seems to be a need for a general solution to this problem.

Why You Shouldn't Use This Tool (And Also, Why You Might Anyway)

Confirmation dialogs suck. You know, the little annoying popup-window that says "Are you sure you want to format your hard drive?". They suck, mainly because they're so predictable, that we get in the habit of hitting OK without even looking at them, only to hit OK that one time, where we didn't mean it. Never the less, they might be better than nothing.

The alternative is to implement undo, so the action takes place immediately, but the user can change his mind and undo the harm. Unfortunately, there are two problems with this approach: (a) implementing undo is hard, especially on top of today's RDBMS's; and (b) constructing a good UI for an undoable world is hard. So confirmation dialogs may be better than nothing, at least in the short term.

Under The Hood

There's a proc, ad_confirm_dlg in /packages/acs-core/widgets-procs.tcl. It's really simple. It will pop up a javascript confirmation dialog and, if the user hits ok, redirect to the URL provided.

If you or our client don't like javascript, however, or if you have needs for more customization, you can use the script, /shared/confirm.tcl. It takes a bunch of parameters and does appropriate redirects. The most commonly used arguments are:

Don't forget to pass it absolute URLs, or it will fail.

Future Improvements

If we want to make the choice between javascript and redirect transparent to the developer, we need to translate the yes-URL from a relative URL into an absolute URL, with respect to ns_conn url. We also need to figure out the URL of the calling page, which could be done from a combination of ns_conn url and ns_getform. It's up to the calling developer to make sure that the page is idempotent, that is, that we can get back to the same page with the same request that got to it the first time (e.g. a counter would not fulfill this requirement, since the number change each time for the same request).

One useful addition would be to let the user say "I don't want to see any more confirmation dialogs for this action". This would require that we pass along a unique identifier for the action in question (something derived from the URL would probably make sense); it would also require that we record the user's preferences for each type of action (a' la dont_spam_me_p); and it would require us to check against this table at each confirmation. All doable.


lars@pinds.com.