On 1/25/06, Laurie Harper <[EMAIL PROTECTED]> wrote: > > 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
On 1/22/06, Craig McClanahan wrote: > > I doubt there is any clean backwards-compatible approach to dealing with > this ... the best thing I can think of is to switch the default behavior to > not listening to the cancel button *unless* a context init parameter is set, > which says (in effect) "this application knows how to deal with cancel > semantics in *all* of its actions". But I think we should do *something* > about it. IMO we should at a minimum do Craig's suggestion of a global option to turn this behaviour on/off. If we then also want to provide more fine grained control, then my preference is the first option in Laurie's list - add a new attritbute to the action mapping. Niall --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
