We actually now have gone for a similar approach. We have defined a Mapper class that encapsulate Mappings and MappedObjects, each Mapping being a relationship between one or more MappedObjects and containing the name of the fields to "import/export". We also created the notion of Converters, meaning that each individual Mapping can use its own Converter. If there is a conversion problem, the Mapper call the ConvertExceptionHandler which has been provided during its initialization. This handler can easily create ActionError. Initialization of Mappers will be done by an XML config file, using the digester. Also each MappedObject can define its own Getter and Setter classes, allowing us to not only support JavaBeans, but also query strings, query and result buffers, etc. This mapper functionality will be used at different stages: during the validation of a form (ActionForm.validate()), during the parsing/handling of backend result messages, and whenever we need to transfer data from one object to another. It will include other features such as object creation during the mapping, internationalization, the possibility to use mappers within a mapper in order to process tree structures. I think Struts would benefit a lot of such addition. Form validation is on the to do list for Struts 1.1, but I'm not sure if anybody has done some work in this area already... Whoever is working on this should really consider the fact that validating user input is not just about parsing text but also about creating the corresponding objects. Therefore it would be great if the Struts validation feature allows you to do this as well. Otherwise the risk is that the validation is done twice: a first time when validating the form attributes, and a second time when creating objects. I strongly recommend to envision validation and object creation in one single framework. Fran�ois Rey Financial WebSuite Capco http://www.capco.com/ -----Original Message----- From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] Sent: 07 May 2001 23:31 To: Rey Francois Subject: Re[2]: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.) Hello Rey, Some time ago I implement similar mechanism to support validation at string2object conversion phase. - BaseActionForm - class extended from ActionForm and contains base logic to support string2object conversion with i18n support with to special methods - import() and export() - public void import( Object entity, HttpServletRequest request, ActionErrors errors ) throws ServletException this method takes entity and converts it's properties from objects to string values with i18n support. All handled errors are in errors container after the conversion process. - public Object export( EntityBean entity, HttpServletRequest request, ActionErrors errors ) throws ServletException this method takes string properties from current form and converts its to the target types with i18n support. All successfully converted values will be written to the object and all handled errors will be written to the errors container. - each form extends BaseActionForm and implements its own versions of export() and import() methods to support it's own version of string2object conversion - import() method will be called at init form process and export() method will called at start of perform method in Action class to init data object from string values collected from the form. - such approach let me to concern all conversion logic in two methods and avoid init of conversion utilites at every setXXX/getXXX call. Monday, May 07, 2001, 5:18:06 PM, you wrote: RF> It has been a while since David replied to my post, but it's only now that I RF> get a chance to work on this aspect in our case. I have been giving this RF> further thoughts and have chosen an approach which I'm now starting to RF> implement: RF> - The ActionForm will be derived into a base class which will contain two RF> lists: the list of errors (ActionErrors instance) and a list of property RF> objects RF> - The property object is encapsulating the name of the property, the string RF> value, the object value, each of them having get/set methods. RF> - The ActionForm implements protected generic get/set methods for string and RF> object values. String get/set methods are used by the plain getXXX/setXXX of RF> the form, while the generic get/set methods for object values are used RF> externally, by whatever logic needs to get object values out of the form. RF> When setting the string value, the corresponding object value is set as well RF> using the provided format class, and vice-versa. RF> - The action form contains helper methods for adding and getting errors. RF> This is particularly useful when a (backend) validation is also performed in RF> the Action: it can now add errors to the form and forward to the input page RF> in case of validation error. RF> - One can also create property objects that do not correspond to one RF> property, but several. For example, a date can be composed of three text RF> fields. In order to allow this, it should be possible to provide a custom RF> implementation of a property object where the getObjectValue() method RF> contains a custom logic for creating a date object out of several string RF> fields. RF> - Validation will automatically be triggered by setting a String value on RF> the ActionForm. String are parsed into objects and parse error will be RF> stored in the error list. RF> There are much more details to sort such as initialization and i18n, but I RF> hope I gave the basic idea. I'd be happy to get any comments on this. RF> Fran�ois Rey RF> Financial WebSuite RF> Capco RF> http://www.capco.com/ -- Best regards, Oleg mailto:[EMAIL PROTECTED] ************************************************************************ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***********************************************************************
