[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]
