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.
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:
message
what you want displayed to the user.
yes_url
will redirect to this URL if the user
clicks OK or yes.
no_url
will redirect to this URL if the user
clicks Cancel or no (usually the page we came from).
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.