Niall, Okay. I understand now.... I now prefer throwing an exception because it stops a corner case which I haven't mentioned yet. I was going to ask if we should also remove the CANCEL_KEY from the request attribute if cancelling is disabled, but the Exception won't even let it pass.
So I guess this is the docket: * Rename "validateCancelable" to "cancellable". Kudos for Ted for catching it since our DispatchActions use cancelled() with two L's * Throw an Exception in processValidate() if the html.CANCEL token is present. But what Exception should be thrown, just an Exception, a RuntimeException, or a subclass of Exception (InvalidCancelRequestException)?? I prefer a subclass so that the <exception> block can handle this unique case, otherwise you can't do it declaratively. I'll work on it tonight. I just need a roadmap. Thanks guys. Paul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
