Actually, having an interceptor makes some sense in this case.
How can interceptors "short circuit" the stack and action to return a
result code? The ideal situation here would be that the "protector"
interceptor is above the validation interceptor, checks for the form
token, and chucks an error result code, protecting the validators from
null parameters and so on.
I can't see anything in the documentation about achieving this - the
ActionInvocation javadoc suggests that
ActionInvocation.setResultCode() will not short-circuit the stack, and
that the action's own result code will override the interceptor-set
result.
Andy.
On 24 Jan 2009, at 17:56, Dave Newton wrote:
Andy Sykes wrote:
Cheers for the suggestions - I guess I was just looking for a
sanity check from the list.
It seems reasonable to me--the functionality *could* be wrapped up
in an interceptor, which might be marginally cleaner, but it's one
of those judgment calls that in real life I probably wouldn't care
much about.
The reasoning behind wanting to do this is my users are somewhat
curious, and are prone to poking. I'd prefer for them to not see
blank pages, stack traces, or otherwise!
Darn users... this is a pretty typical requirement and is one of the
reason workflow "engines" came about; they can handle simple cases
like this as well as disallowing jumps into the middle of multi-step
processes etc.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
