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

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

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
> I expect lots of interesting discussion on each and on how to integrate
them.

Sounds great!


> Martin Cooper
> Tumbleweed Communications
> 
> At 02:46 PM 2/28/01 +1100, Nick Pellow wrote:
> >Martin,
> >
> >martin.cooper@tumbleweed.com wrote:
> > >
> > > At 11:17 AM 2/28/01 +1100, Nick Pellow wrote:
> > > >I am very new to struts as is, but as I far as I can tell from
reading
> > > >the implementation of the above method,
> > > >the ActionForm can only have String properties. Is this correct?
> > > >
> > > >If so, it would be nice if the ActionForm could support types other
than
> > > >String and the
> > > >struts engine would convert these in a similar fashion as Ant does to
> > > >the attributes in the xml build file.
> > >
> > > Actually, Struts will attempt to convert values as it populates a form
> > > bean. This is done in BeanUtils.populate(), which is called right at
the
> > > end of RequestUtils.populate().
> >
> >Ooops, thats what I was looking for but did not find.
> >
> > > However, the problem is what to do if it
> > > can't be converted. For example, if I define a form bean property as
an
> > > int, and the request contains "abc", what should Struts do?
> >
> >Struts could create an ActionErrors object with an ActionError for each
> >conversion error.
> >If an error does get raised at that early stage, then one will no doubt
> >be raised later on
> >in the Action. The difference is that the coder has to
> >a) check for the conversion error again,
> >b) raise an error again.
> >It also means that checking for such user mistakes is spread across
> >mulitple layers in the application
> >and also across multiple components within the system. I think it would
> >be nice to centralize
> >such type checking in one part of the system.
> >
> >
> >The error message strings could be defined in a similar fashion to
> >errors.header and errors.footer.
> >Maybe something like:
> >errors.conversion.NumberFormatException=You must enter a number for the
> >{0} field, not {1}.
> >
> >Then when Struts comes across a type error, it raises the error then and
> >there, using a resource
> >such as the one above to report to the user.
> >
> >As mentioned earlier in this thread this option could be configurable in
> >Struts as it may not
> >always be desirable.
> >
> > > In 1.0, it will set the property to a (configurable) default value,
but
> > > that's not a good solution when there's no obvious candidate meaning
> > > "invalid" (e.g. for a boolean). It also destroys the original user
input,
> > > so when validate() fails and returns the user to the input form, you
can no
> > > longer display to them the mistake they made. (By default, in the
situation
> > > I described above, the user would see "0" where they entered "abc".)
> > >
> > > So it's really best if form bean properties are all strings. What you
*can*
> > > do, though, is have your validate() method check that the value can be
> > > converted to what you want, and return an error if it can't. For
example,
> > > you might use Integer.parseInt() to ensure that a valid integer was
> > entered.
> >
> >If the validate() method does the type checking then we must implement
> >type
> >conversion code and type checking code in every single form bean we
> >write!
> >On large systems, this is sometimes very unfun.
> >
> >Any thoughts?
> >
> >Regards,
> >Nick
> >
> >
> >
> > >
> > > --
> > > Martin Cooper
> > > Tumbleweed Communications

************************************************************************
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
The Capital Markets Company.

http://www.capco.com
***********************************************************************

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

[David Winterfeldt <dw...@yahoo.com>]

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/