Re[2]: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.)

[Oleg V Alexeev <go...@penza.net>]

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:gonza@penza.net