On 1/23/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 3:37 PM -0500 1/23/06, Frank W. Zammetti wrote:

> The proposed solution requires that the person intentionally using
> this feature make one further indication in the struts-config file,
> reinforcing the logical contract that says "it is ok to invoke this
> action with an invalid form even though I have set "validate='true'".
> The key point here is that you are explicitly turning on attention to
> the "cancel" parameter for any action (path) that accepts it, leaving
> all other actions invulnerable to the "attack".

I like that solution but it's not backwards compatible which I thought
was what we were trying to make happen as well as fix the problem. If
someone updates their code with these latest jars they will have to
find all the spots in the config where they want to allow a cancel to
take place. I'm not saying that's a bad thing, it's just that if the
code isn't going to be backwards compatible we might have other
options to improve upon the situation.

I remember now why I didn't really like the way the cancel mechanism
initially was designed. It's ok for regular actions since you only
have one method and you can easily check for 'isCanceled' and do what
you need to do. For DispatchActions though this was a bit of a pain
unless you provided a base class with an execute method to catch the
cancel. If you didn't use a base class you could potentially be
entering several dispatch methods from the same form (imagine a case
where you might have an updateFooBar and insertFooBar dispatch
method). In both methods you now have to test for 'isCancelled'. It
just never felt right to me. To me at least it always seemed better to
just go to a "cancelled" method if that's what I want to do vs having
to check everywhere for "isCancelled."

I guess it is easier to go through and fix your actionMappings vs
moving some "isCancelled" block in your Action into a "canceled"
method, so the solution proposed is ok. I just think you might get
more people using html:cancel if it had the slightly different
behavior of executing a cancel method. I guess that is too radical a
change though:)

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to