Probably you misunderstood my statements or misunderstood the capability of the common-beanutils package.
If someone designs a form bean with a non-string property, say, the contactid as native int property. The common-beanutils package would not be able to cache the conversion error and then re-display the user's original input, if that input is a invalid integer, say 123A. More troubles arise when the JSP page has a lot of fields, say, 20 fields, for example, if the contactid get a conversion error at the very beginning, then the whole form bean would not be populated appropriately. The user's inputs are wiped out. It is a well known issue of the ActionForm at the moment. And it should be addressed in the future Struts releases. Please be specific and remain context relevant. Jing ----- Original Message ----- From: "Mark Galbreath" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>; "'Jing Zhou'" <[EMAIL PROTECTED]> Sent: Tuesday, August 19, 2003 3:24 PM Subject: RE: exception in actionfrom class. Your first statement is not true and this is a shameless marketing plug for your project. Mark -----Original Message----- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 2:06 PM To: Struts Users Mailing List Subject: Re: exception in actionfrom class. The current Struts 1.1 allows you to design form beans (instances of ActionForm) using only String properties. This because the common-beanutils package is not able to cache conversion exceptions and re-display original user's inputs. You are responsible to validate the string properties (using whatever validation methods) and then invoke the copyProperties() method in the common-beanutils package to copy and/or convert the string properties to your domain objects, for example, your ContactInfo objects. If you really want to catch the conversion exceptions and display them to screen, check the HyperFormBean class at http://www.netspread.com The hyper form bean is also an extension of the ActionForm class. But it supports 12 standard types and one custom property interface. It can cache any conversion exceptions and is able to display original user's inputs in case of any errors. The form bean model improves the Struts action form in the following ways: 1) Standard and custom property types are supported. It fits into the common-beanutils package smoothly. 2) Type conversions are performed only one time. (Struts may need one or more times to perform type conversions, one in the copyProperties() method and another possible one in the validation methods) 3) Reduce the usage of reflection. Therefore it gives higher performance. 4) Tools can be designed for designers to compose such form bean model. Carrier has a form bean model composer tab pane where designers could compose whatever form bean model they like, including nested ones. 5) The reset method in the form bean model is view agnostic. You never need to re-write the reset method anymore, anywhere, even if you change your web forms. 6) The validate method in the form bean model is also view agnostic. You could attach built-in or custom validation rules in addition to the required and data type conversion rules. You do not need to re-write the validate method even if you change your web forms in the form bean model. 7) The concept of the runtime property name is a very interesting one, I believe. The runtime property path to a nested property of the hyper form bean could be automatically adapted as needed. 8) The hyper form bean can be persisted and restored systematically. The default persistence mechanism implemented in Carrier allows you to prototype web applications without writing custom codes. It includes CRUD operations on nested form beans. The algorithm that simultaneously achieve above 8 goals is called Wheels. It is so simple just like a wheel - nothing less and nothing more. If it is proved to be right, I wish it could be contributed back to Struts as a contribution package with necessary adaptations for more general requirements. After all, it is an algorithm built on the shoulders of the Struts team :-) So we publish the full source codes of Wheels for public viewers. Jing Netspread Carrier http://www.netspread.com ----- Original Message ----- From: "deepaksawdekar" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 19, 2003 5:08 AM Subject: exception in actionfrom class. I am using the containment design patter for the ActionForm. My action form will look like this. public final class ContactForm extends ActionForm { private ContactInfo contactInfo; public int getContactid() { return contactInfo.getContactId(); } public void setContactid(int ContactId) { this.contactInfo.setContactId(ContactId); } public String getTitle() { return contactInfo.getContactPersInfo().getNameInfo().getTitle(); } public void setTitle(String Title) { this.contactInfo.getContactPersInfo().getNameInfo().setTitle(Title); } . . . . . } the setter methods throughs some exception. Exceptions will be thrown if there is some format validation error. I want to catch this exception and would like to display them on the screen, how can i achive this. Thanks and Regards deepak --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
