But what do you guys mean by lookin for a canceled method in the Action. I think that the best would be to implement a Cancelable interface if your Action is cancelable. You would have to do this in all kind of Actions (DispatchAction too) by the way.
Or is having interfaces very unstrutsish? Tamas On 1/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > On Mon, January 23, 2006 9:54 am, Rick Reumann said: > > 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. > > I'm in the non-DispatchAction camp myself (although who knows, I may be > the only one in that camp!) and I don't have a problem with this. > > > 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:) > > That would be my only concern is backwards-compatibility. Then again, > simply adding the method to the Action class should deal with it always > being present. I would also suggest a default implementation that > returned null but that rendered a response like so: > > <html><head><title>cancel() not present</title></head> > <body>No cancel() method found in requested Action</body></html> > > At least that way it's not just a blank screen, the hole is plugged, and a > developer will know what's going on pretty quickly and easily (a nice log > message in the default implementation saying what the requested Action was > would be nice too). > > Anyone legitimately using isCancelled() functionality would have to move > that related code to cancelled() now to have it all still work, but I tend > to think that's a relatively small group of people being hurt... I for one > would find this solution acceptable. > > Frank > > > 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] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
