Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@apache.org Received: (qmail 22339 invoked from network); 15 Jan 2003 20:29:30 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 15 Jan 2003 20:29:30 -0000 Received: (qmail 7130 invoked by uid 97); 15 Jan 2003 20:28:50 -0000 Delivered-To: qmlist-jakarta-archive-struts-user@jakarta.apache.org Received: (qmail 7012 invoked by uid 97); 15 Jan 2003 20:28:49 -0000 Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list struts-user@jakarta.apache.org Received: (qmail 6929 invoked by uid 98); 15 Jan 2003 20:28:48 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Wed, 15 Jan 2003 12:27:19 -0800 (PST) From: "Craig R. McClanahan" To: Struts Users Mailing List Subject: RE: [Gurus Invited] Why not an Action Based Validator? In-Reply-To: Message-ID: <20030115095909.Y15326-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 15 Jan 2003, Phase Web and Multimedia wrote: > Date: Wed, 15 Jan 2003 08:28:23 -0700 > From: Phase Web and Multimedia > Reply-To: Struts Users Mailing List > To: Struts Users Mailing List > 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: For additional commands, e-mail: