struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict, Paul C" <>
Subject RE: Struts 1.3: Validations and Commands
Date Thu, 27 Jan 2005 15:02:19 GMT

My thoughts are identical. It is more natural to have "process-action" and
"process-view" be separate chains. Because I just completed reading the
commons chains documentation before examining the Struts implementation, I
immediately noticed this incongruity.

Also, because the RequestProcessor is easily composable by the developer, it
would be a good idea to allow "true" to exit the action chain and jump
immediately to the view chain. Otherwise, any custom commands that
developers write have to check the state of the form's validity each time.
That's not a big burden, but it is questionable why this burden needs to be


-----Original Message-----
From: Joe Germuska [] 
Sent: Wednesday, January 26, 2005 10:35 PM
To: Benedict, Paul C; ''
Subject: Re: Struts 1.3: Validations and Commands

At 4:10 PM -0500 1/26/05, Benedict, Paul C wrote:
>Is it the intention of Struts 1.3 to run ExecuteCommand regardless of
>validation failure? Looking at the commands listed in chain-config.xml,
>neither AbstractValidateActionForm or AbstractSelectInput return true if
>validation failed.
>I am curious about this design decision. If validation fails, what use is
>executing the command?

ExecuteCommand does not execute the command if the validation failed, 
but this is because it checks the context to see the state of the 
validation; this is how everything after validation works in the 
current default chain.  (There's actually a protected 
"shouldProcess(Context)" method which could be overridden in a 
subclass to use different rules about whether or not to call the 

The validation steps don't return true, because if it did, the 
"PerformForward" which returns to the input view for the form which 
failed validation would never execute.  AbstractValidateActionForm 
can never return "true" (in the current design), because it doesn't 
deal with putting an ActionForward into the context -- that happens 
in AbstractSelectInput.

I kind of prefer a model which has two chains, an "Action" (request) 
chain and a "View" (response) chain.  In this case, the "goal" of the 
"Action" chain would be to put an ActionForward into the context, and 
any command which did that could return "true" after doing that. 
Then later commands wouldn't have to repeatedly test the context to 
see whether the validation worked.

This is the line I was working along in the ActionContext stuff I was 
posting a lot about a couple of weeks ago.  Unfortunately, I haven't 
had much time to progress past that, but that's how I've been 
thinking about it.  It's another example of something I'd rather hear 
some more ideas on before I commit it (although the delay has been 
more just about my available time.)


Joe Germuska       
"Narrow minds are weapons made for mass destruction"  -The Ex

Notice:  This e-mail message, together with any attachments, contains information of Merck
& Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates
(which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or
MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally
privileged. It is intended solely for the use of the individual or entity named on this message.
 If you are not the intended recipient, and have received this message in error, please notify
us immediately by reply e-mail and then delete it from your system.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message