I supposed I should reply to this on the dev list but since this thread is so long now I figured I'd add a bit more on the topic here. I see Paul/Frank what the concern is, but I think the 'problem' needs to be clarified a bit more. The problem, in my opinion, really only occurs when someone is trying to go to an action through a URL and they intentionally type in the canceled parameter which bypasses the validation procedure. On an action where you do truly want to support a cancelled operation, I believe Struts is handling things just fine. Am I wrong here Paul?
In other words, you definitely would want validation skipped on actions where you are going to provide a cancel button. That's the whole point of cancelling - to typically leave the form without having completed it. You also would still want the execute method to process so you could handle the 'isCancelled' and do any cleanup or other things. I think on forms where you provide a Cancel everything works fine. It's the fact that you can spoof a canceled to other actions by typing in the URL that causes the potential problem. The solution I would like to see is if the canceled param is passed to the Action, it tries to look for a "canceled" method in the Action. I know this makes the Action like a DispatchAction but in this regard I don't think the non-Dispatch folks would disapprove too much. In other words, execute is never performed (not is a dispatch method performed) only the 'cancelled' method is looked for. Validation is skipped as usual for this cancelled method. This is better than having to use the current "isCancelled" since you are never in the your Action's execute or Action dispatch method. Another option might be to force an include in the action mapping of 'canCancel=true' for Actions that are cancelable. That might be more difficult to figure out how to handle though as far as the life-cycle goes. I haven't thought that one through. What do you guys think about just making sure a "cancelled' method is looked for when canceling? The problem will be that this won't be backward compatible now that I think about it. Blah oh well. I tried:) The description by Laurie below is On 1/22/06, Laurie Harper <[EMAIL PROTECTED]> wrote: > [Moved to a top-level thread, as this doesn't have anything to do with > (either of) the thread(s) it was nested in! :-)] > > > I think this thread deserves discussion on the dev list, but before I > move it over I thought I'd post a summary to make sure I've captured all > the arguments. I've also added preliminary thoughts in how to resolve > the issue at the end of this post, though that discussion definitely > ought to proceed on the dev list I guess. > > I'll re-post this message to the dev list later today if I haven't > missed anything important below: > > > > * Issue: addition of a 'org.apache.struts.action.CANCEL' parameter to > any request will cause validation to be skipped, but the rest of the > request processing / action invocation cycle to proceed normally > > * Consequence: any action which proceeds assuming that validation has > completed successfully and which doesn't explicitly check isCanceled() > is proceeding on a broken assumption > > * Questions: > > - why doesn't Struts call validate() on a cancelled request? > > If a request is canceled it usually means validations don't > apply since the implication is that any user input will be > thrown away. Users shouldn't be required to supply valid > inputs for actions they are canceling. > > - why does Struts still call Action.execute() for a canceled request? > > Since you may still want to act on a canceled request (e.g. > to clean up resources stored in the session). (Some of?) the > DispactAction variants dispatch to a special method and aren't > subject to the consequences listed above, but most action > implementations don't. > > - why does Struts still populate the action form on a cancelled request? > > If inputs are going to be thrown away anyway, why process > them by populating the action form? [Commentary: I believe > this behaviour makes sense since it preserves a standard > way to access the request data, should you want to, regardless > of whether the action was canceled. You could argue that > either way...] > > > Here's my first thoughts on possible approaches to addressing the > problem, to kick off further discussion on the dev list: > > - SAF1.2 and before: ? document, don't fix? add config req'm'ts on > action mapping? Refer to discussion on user list for various options. > > - SAF1.3+: make cancel processing a command which you have to include in > your request processing chain, and perhaps disclude it by default? [I'm > not familiar enough with how you deploy chains on a per-action basis to > know if this is the right way to do it...] > > - WW2/SAF2: implement cancel processing as an interceptor and either > disclude it from default stack or require an action to implement an > interface declaring that cancel processing should happen? > > L. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Rick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
