I know that none of this would make it's way into the 1.1 release. I also know that we are looking at potential significant changes in 2.0. Maybe this would be a discussion we can put in our cap for future thought.
On Wed, 15 Jan 2003, Phase Web and Multimedia wrote: > Date: Wed, 15 Jan 2003 08:28:23 -0700 > From: Phase Web and Multimedia <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: RE: [Gurus Invited] Why not an Action Based Validator? > > Thanks. I understand the logic of having the form handle simple validation > to avoid unnessecary Action invocation. That does make sense. > That was indeed the original intent of validate() in ActionForms -- to focus on the "user interface" type validations rather than business rules validations. There's more than one valid :-) use case, so I don't see us getting rid of this even if we were to add something for business layer validations as well. It would be interesting to explore a more structured environment for creating validation frameworks for business rules checking as well. Perhaps the standard actions package (org.apache.struts.actions) could offer a base class (along the lines proposed earlier in this thread) with the appropriate model built in for this. I haven't played with it myself, but I understand that you can use commons-validator classes directly to configure your business tier validations -- including the ability to create custom validation methods as needed. All that would be necessary is a way to read in the configuration of these validators from some XML file as well. Or, you could just write your validations as standard Java logic in the validate() method. One advantage you didn't list for doing all the validations together is a human factors one -- the user can find out about *all* their errors in one round trip to the server. For example, if you make a syntactic error in one field (that could be caught by UI-level validation) and a semantic error in another field (invalid customer account number), it takes two round trips to fix all the errors if the validations are split, but only one trip if they are joined. > Thanks, > Brandon Goodin Craig -- 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]>
