Thanks. I understand the logic of having the form handle simple validation to avoid unnessecary Action invocation. That does make sense.
Thanks, Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -----Original Message----- From: Robert Taylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:05 AM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: [Gurus Invited] Why not an Action Based Validator? I think validation was originally placed in ActionForm in an effort to simplify simple validation on the form fields. From an OO view point, this allows an ActionForm to remain cohesive. It is responsible for providing a simple API to facilitate access to data in the HTTP request. It only makes sense that it should know how to validate that same data. The Action class implements a command pattern which usually contains a single method which is invoked by its parent framework and executes some business logic. If we start adding a method here or a method there which may be useful for 80% of the users then would it not violate the command pattern and introduce additional complexity into the Struts framework? I think the original intention for separating validation was that since all data in the request entered either from a GET or POST request is represented as strings, then there was a real need to determine if a user id was an integer or if a character string represenated a valid date before the data could even be used in the Action class. Why even bother invoking the Action class (for a particular mapping) if the user input was invalid? This allows Struts to avoid some useless overhead and speed up an already useless server side roundtrip. Yes, this could be done with JavaScript, but we all know that is not dependable. I agree that since Struts is a presentation framework it should be able to satisfy a large number of user requirements. But there is a fine line between satisfying those requirements and violating the framework ( a line only few can walk - Craig, Ted, etc...). Why not look at how the existing framework can be used to satisfy your requirements? The ValidatorActionForm is a complex (and loose) implementation of a Visitor pattern. It allows the form to be extended without actually extending it. In effect, you could place all pre-processing validation in a custom Validator. This way your ValidatorActionForm remains simple and reusable and validation can be executed based on the form name, action path, and/or page number. This also allows you to encapsulate all validation routines in a single or a family of Validator's. Struts also provides a way to abstract exception handling from your Action class so that if you get a runtime exception you can declare the handlers in the struts-config file. If you leverage DynaActionValidatorForm the Action class becomes very clean and devoid of most business logic and acts (IMHO as it should) as a simple delegate to the business or service layer. Personally, I like to use the Struts validation framework for simple validation. My Action classes delegate to a service layer which delegates to reusuable business objects. The service layer contains application validation and the business objects contains model validation. All throw the appropriate exception which is propogated to the Action class where it is handled appropriately. In closing, Struts is a simple open source presentation framework which by itself is very flexible...and you can modify it if it doesn't meet your specific requirements. I hope I understood your question, answered appropriately, and didn't just ramble on. robert > -----Original Message----- > From: Andrew Hill [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 15, 2003 5:24 AM > To: Struts Users Mailing List > Subject: RE: [Gurus Invited] Why not an Action Based Validator? > > > +1 > > -----Original Message----- > From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 15 January 2003 18:30 > To: Struts Users Mailing List > Subject: RE: [Gurus Invited] Why not an Action Based Validator? > > > But that is my whole point. Complex validation or not. Why don't we handle > both types of validation in the SAME class. I don't want to beat this into > the ground. But, it just seems organizationaly better in my mind to handle > validation on the Action level. With all the great minds on this project I > am certain that there is a good design reason for placing validate in the > ActionForm. I am just curious what it is. > > Thanks, > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > > -----Original Message----- > From: Gemes Tibor [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 15, 2003 2:24 AM > To: Struts Users Mailing List > Subject: Re: [Gurus Invited] Why not an Action Based Validator? > > > 2003. janu�r 15. 10:13 d�tummal Phase Web and Multimedia ezt �rtad: > > But, can the Validator be called/used from within the action class? > > I use the Validator to check if the input is in the appropriate > Domain (int, > float, mask, date, etc) which can be checked "static". However there are > some > validations which require calls to the model. These are checked in the > Action. And these are far more complex so cannot be declared in an xml. > > > failure and my input forwards back to the jsp then the page explodes > because > > the collections are empty. So, what I need to do is populate the > collections > > in the ValidatorActionForm again > > For this I put the form into session scope or I give the 'input' attribute > for > the mapping not the jsp but the action which prepopulates the SELECTs and > forwards to the jsp. > > Hth, > > Tib > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
