Joe, 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 carried. Thanks, Paul -----Original Message----- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 26, 2005 10:35 PM To: Benedict, Paul C; 'dev@struts.apache.org' 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 command.) 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 -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
