Paul Benedict wrote:
Laurie,
Do we have a proprosed solution? I volunteer to write it, whatever we decide
on, unless a
committer feels it is more appropriate for him/her to write it.
I believe we have several proposed solutions:
- add an action-mapping config option to enable cancel processing, and
ignore the cancel request parameter if the action mapping isn't
configured to use it
- add an Action.canceled() method which would be called instead of
Action.execute() if the cancel parameter is included in the request, and
make the default implementation return an error response
- add a Cancelable interface which an Action must implement to get
cancel processing; ignore the cancel param if the interface isn't
implemented
I've listed those in my personal order of preference ;-) I think an
additional method on Action with a default implementation is better than
just a marker interface, but it's still more intrusive than I'd like.
The config-based solution is a) easiest to deal with during an upgrade
(no need to change any code, existing action implementations that check
isCancelled will work without re-organizing them, etc.); and b) a clean
declarative way of specifying the desired behaviour. It also has the
advantage of working identically regardless of if you're using Action,
DispatchAction, or whatever.
The disadvantage is that it may be slightly harder to implement in
Action 1.2.x than in 1.3, but I don't think that's insurmountable if we
agree it's the right approach.
Oh, and that's ignoring the 'do we need it' / 'does anyone use this'
type questions. I believe this *is* something that's needed, even if
it's only used by some people. Removing html:cancel and the associated
processing doesn't seem to be a viable option, IMHO ;-)
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
