struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rey Francois <francois....@capco.com>
Subject RE: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.)
Date Thu, 01 Mar 2001 07:20:59 GMT

Our intention is to use ActionForms as converters to object values.
Typically the information entered in a form is going to be used as
parameters to a backend request or will go into some object or bean that
will be sent to the backend. One should not send to the backend the
ActionForm object itself because this would make the backend interface
dependent on the front-end. So somehow the information has to be extracted
form the ActionForm. With JDBC, ActionForm values will be used to set
parameters of a Statement or PreparedStatement. With an EJB backend a Value
Object may have to be populated. In other cases it can be a Request object
that is part of the public interface to the backend, or in the case of a JCA
interface, a Record object.

In our approach the ActionForm setter methods use the Format classes to
validate and create correct object values and catch any exception resulting
from an invalid input, storing corresponding error messages in a collection
that can be used in the validate(). Objects resulting from valid parsed
inputs are stored internally in a hashtable, and can be retrieved within
Action.perform() by calling a generic getValue method on the ActionForm.

We have not implemented this yet, but this is how we intend to implement
ActionForms. Comments on this approach are welcomed.

Fran├žois Rey
Financial WebSuite
The Capital Markets Company
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 <francois.rey@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
The Capital Markets Company.

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


Mime
View raw message