RE: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.)

[Rey Francois <Fr...@capco.com>]

It has been a while since David replied to my post, but it's only now that I
get a chance to work on this aspect in our case. I have been giving this
further thoughts and have chosen an approach which I'm now starting to
implement:

- The ActionForm will be derived into a base class which will contain two
lists: the list of errors (ActionErrors instance) and a list of property
objects
- The property object is encapsulating the name of the property, the string
value, the object value, each of them having get/set methods.
- The ActionForm implements protected generic get/set methods for string and
object values. String get/set methods are used by the plain getXXX/setXXX of
the form, while the generic get/set methods for object values are used
externally, by whatever logic needs to get object values out of the form.
When setting the string value, the corresponding object value is set as well
using the provided format class, and vice-versa.
- The action form contains helper methods for adding and getting errors.
This is particularly useful when a (backend) validation is also performed in
the Action: it can now add errors to the form and forward to the input page
in case of validation error.
- One can also create property objects that do not correspond to one
property, but several. For example, a date can be composed of three text
fields. In order to allow this, it should be possible to provide a custom
implementation of a property object where the getObjectValue() method
contains a custom logic for creating a date object out of several string
fields.
- Validation will automatically be triggered by setting a String value on
the ActionForm. String are parsed into objects and parse error will be
stored in the error list.

There are much more details to sort such as initialization and i18n, but I
hope I gave the basic idea. I'd be happy to get any comments on this.

François Rey
Financial WebSuite
Capco
http://www.capco.com/


-----Original Message-----
From: David Winterfeldt [mailto:dwinterfeldt@yahoo.com]
Sent: 28 February 2001 18:21
To: struts-dev@jakarta.apache.org
Subject: RE: Validating bean properties (WAS: Re: Stupd question
aboutStru ts and EJB.)


I think it is good to tie together the valdation and
conversion of the strings to objects and objects to
properly formatted strings.  

I'm curious to know if how you have and/or plan to tie
this in with your beans (ActionForm).  Will they just
have setters and getters for strings and you will use
your format class as you need it outside of the beans
or do you have the functionality built into your bean
(custom PropertyDescriptors and/or something like 
String getDateAsText(), Date getDateValue()).

David

--- Rey Francois <fr...@capco.com> wrote:
> See also the posting I made a few days ago regarding
> validation. I've pasted
> it below.
> The main idea is to use the java.text.Format class
> to do the validation and
> transformation
> between Strings and objects (both ways). The XML
> customization you're
> talking about should achieve
> this double goal: validation and transformation.
> 
> François Rey
> Financial WebSuite
> The Capital Markets Company
> http://www.capco.com/
> 
> --------------------- begin paste
> ----------------------------------------
> 
> In our case, we have chosen to use the
> java.text.Format as a superclass of
> all our validation and formatting classes. I would
> suggest Struts to
> consider this approach. Our decision derives from
> the following
> requirements:
> 
> 1 Validation of Strings data according to a
> specified format
> The basic requirement is to validate that a string
> complies to a specified
> format. For example, for a string representing a
> date, the requirement is to
> make sure it is of the form: dd/mm/yyyy.
> 
> 2 Parsing Strings to Objects and vice-versa
> Beyond the simple aspect of validating the format of
> an input string, it is
> also often required to transform the validated
> string into a usable form for
> further processing. In Java this means creating an
> object instance from the
> string. With the date example, this could mean
> creating a java.util.Date
> object.
> On the other hand, it is also required to perform
> the reverse operation. In
> the case of an instance of a java.util.Date, it
> should be possible to get a
> string representation of it according to a specified
> format.
> 
> 3 String buffer parsing and formatting
> It should be easy to parse only a certain part of a
> larger string when the
> latter contains the formatting of several elements.
> Conversely, it should be
> easy to append the string representation of an
> object to an existing string.
> This can be useful for example in the context of
> marshalling object
> instances into an XML representation.
> 
> 4 Independence of the usage context
> The classes involved should be coupled to any
> context of usage. This is to
> allow maximum reuse of the logic in various
> contexts. For example the
> framework should not depend on the HTTP request of
> the Servlet API.
> This should enable the creation of a library of
> formatter that can be used
> in various projects. This library can contain basic
> formatters, but also
> more business oriented ones such as account number
> formatting, etc.
> 
> 5 Internationalization
> In some cases it is necessary to have the parsing
> and validation processing
> aware of locale-specific factors. The date example
> is again a very good
> illustration of this requirement, whereby in the
> United States dates are of
> the form mm/dd/yyyy, while in Europe dates are of
> the form dd/mm/yyyy. In
> the context of a graphical user interface, this is
> an important requirement.
> 
> The java.text.Format class satisfies all the above
> requirements. It is a
> standard Java object, so using it should be
> consistent with future Java
> developments. Finally, J2SE already proposes some
> formatters for numeric
> values, date, and messages.
> 
> In our context, these format classes will be used
> for:
> - HTTP request parameter validation
> - Handling of request and return buffer to and from
> legacy systems
> - Displaying of the data elements in an HTML
> front-end
> 
> Eventually, beyond the use of Format classes, we
> intend to create a sort of
> format class instance pool, whereby pre-initialized
> format classes are
> stored for repetitive usage. This avoids the
> creation and initialization of
> an object each time a validation/formatting has to
> be performed. The Struts
> digester would be a great tool for initializing this
> pool.
> 
> Comments welcomed!
> 
> --------------------------- end paste
> ---------------------------------------
> 
> -----Original Message-----
> From: Nick Pellow
> [mailto:nick@cortexebusiness.com.au]
> Sent: 28 February 2001 08:07
> To: struts-user@jakarta.apache.org
> Cc: struts-dev@jakarta.apache.org
> Subject: Re: Validating bean properties (WAS: Re:
> Stupd question
> aboutStruts and EJB.)
> 
> 
> Martin, 
> 
> 
> martin.cooper@tumbleweed.com wrote:
> > 
> > Actually, the plan is to build exactly this type
> of validation into Struts
> > 1.1. In particular, I am hoping to incorporate it
> into the automated bean
> > creation tool, one way or another.
> 
> Yup, I minutes after my lost post, I received the
> post for Volunteer for
> Validation
> Framework. Wish I had read that first! The
> validation stuff sure could
> be interesting.
> 
> > The idea is to define your bean(s) in an XML file,
> and have the tool
> > generate the actual bean code for you. When you
> define a bean, you can
> > specify its type, along with some other validation
> rules (yet to be
> > determined). The tool will create a validate()
> method, and that method
> will
> > populate ActionErrors as appropriate.
> 
> > My original thought was to generate code based on
> the validation rules.
> > However, David Winterfeldt has written an
> interesting validator that runs
> > off an XML spec directly. This may be a better
> approach, in that you can
> > modify the rules later without recreating the
> bean, among other things.
> 
> I was considering an approach where coders wrote
> validation code in Java
> (we all know java!)
> yet the Struts framework executed it. You would
> extend or implement a
> common java class/interface defining a single
> method, 
> public ValidationErrors validate();  say.
> That is then mapped to the form field in an xml file
> somewhere.
> 
> Struts, however could ship all the standard
> validations (such as Strings
> to ints)
> together.
> 
> It is something I have not given much thought to
> yet, but would be
> interested in
> exploring further.
> 
> 
> > I'm not sure how this will all fall out in the
> end, but I will be very
> > surprised if Struts 1.1 does not include ways of
> automating the creation
> of
> > form beans, and ways of specifying validation
> rules without writing code.
> > There are several people interested in working on
> each of these topics, so
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

************************************************************************
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
***********************************************************************

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