Return-Path: Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list struts-dev@jakarta.apache.org Received: (qmail 66658 invoked from network); 14 Jun 2000 13:47:54 -0000 Received: from unknown (HELO narwhal.inst.strykercorp.com) (206.175.178.210) by locus.apache.org with SMTP; 14 Jun 2000 13:47:54 -0000 Received: (qmail 1378 invoked by uid 500); 14 Jun 2000 13:45:12 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Jun 2000 13:45:12 -0000 Date: Wed, 14 Jun 2000 09:45:12 -0400 (EDT) From: "Hutchison, Jeff" To: struts-dev@jakarta.apache.org Subject: Re: AW: AW: ANNOUNCEMENT: New JAKARTA-STRUTS Subproject In-Reply-To: <571B91EF5DD1D211A04900A0C9EAD2C849021F@pc07207.ina.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N I'm extracting a portion of this from a long message posted to struts-user because I wanted to comment on the development of the FormBeans. McClanahan, Craig wrote (I think): > > Self-validating form beans sound cool at first blush, but consider > > one issue about the process flow -- one of the roles of the form > > bean itself is to faithfully represent the last set of input > > fields that the user entered (whether the whole transaction is > > semantically valid or not). If the setter methods in your form > > bean, for example, were to through IllegalArgumentException on > > invalid values, your form bean would not be completely up to date > > -- so that when you redisplayed the the form to the user again, it > > wouldn't show the bad value that he/she actually entered. > > I would suggest that validation be done either in the action class > > itself, or in the "data access layer" bean or EJB that actually > > represents your business objects. Nestel, Frank wrote: > Not sure if we are thinking about the same thing, I liked the > approach in the "Advanced form processing using JSP" artivle by > Govind Seshadri on JavaWorld. Extending that idea every FormBean > should be required to have a validate() method which returns a data > structure (Hashtable) about postion and type of error... I agree, self-validating beans do sound cool. I think the validate() approach mentioned by Frank might be useful. I'm reminded of two different types of validation that Brett McLaughlin mentioned in a presentation I saw at the O'Reilly Java conference earlier this year. Coarse Grained Validation - generic validation of data types: required, numeric, date, phone, email, etc... This might be appropriate for validation within either the browser (using JavaScript) or in a FormBean validate() method. For the validate() approach, each setter can optionally call a superclass addValidationError() method, and the validate() method can check to see if any errors were added and return a boolean signalling success or failure. Fine Grained Validation - very specific validation of business rules: probably best done in the data access layer. -jh -- Jeff Hutchison Stryker Instruments Kalamazoo, MI