Frank, I am getting your emails delivered twice to the list today. Are you click happy today? :) haha Maybe mine are getting delivered twice; please tell me if so.
As for the bug/issue, I mainly use MappingDispatchAction and so there's no reason to specifically code for isCancelled().... BUT I was looking at DispatchAction and that always calls the cancelled() method, but if it returns "null" it continues to the expected method. I kind of find that strange. "null" is an appropriate return value in Struts which means that you handled the request directly. To check for null here and then continue going is also a bug, in my opinion. That's another issue to debate. I am sure someone may want this forwarded to the struts-dev boards, but I hate signing up to boards just for sending one email.... Now for proposing fixing. I really believe it's an error to populate the form, bypass validation, and invoke the destination in *all cases* for cancelling. What makes this a difficult problem to solve is that it's been around for many eons of Struts :) Ted's solution is good but do we really want to that? I know more than a few programs that require cleaning up from a valid cancel before needing to forward off. Personally, for the time being anyhow, I still prefer setting a controller level property that assumes nothing may be canceled unless the action says so. Why? I have more actions that have no use for canceling than ones that do. Did you notice validation is skipped in processValidate() when the request attribute is set from processPopulate()? We should try to determine what logic is appropriate to remove the cancel attribute, if need be. 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]
