struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Pellow <n...@cortexebusiness.com.au>
Subject Re: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.)
Date Thu, 01 Mar 2001 23:39:26 GMT


Spencer Smith wrote:
> 
> Are you talking about modifying the actual struts classes or extending them
> in myFormBeans Pages?
> 
> The problem I have run into is that at first, I wanted to make some minor
> mods to the Struts classes and add a couple of new entries into the
> struts-html.tld files, but I was told be the lead guy that that was not a
> viable option, because each time we upgraded struts we would have to change
> the code all over again, and deploying it all over it a real pain.
> 
> I was actually looking into using Perl5 regular expressions to use
> Auto-Validation with my FormBeans pages.
> 
> I think this is a very viable solution as long as you don't have to mod the
> struts ActionForm page.
> 
> Maybe the way to go is to create a generic new generic Validator class that
> will do something like the following:
> 
> validateEmail
> validateRange
> validateText
> etc, etc.
> 
> What do you think?

My thoughts:

I think generic validators are a good idea, however I do not think
that Struts is the right place for validation of business rules if that
is what you mean.

I would rather do business logic checks at the top of the business
layer, such as in the
setters on an EJB. This allows for better code re-use as at JSP/tag
level there could
potentially be many places that call such an EJB setter mehtod.

The only validation I would do in the JSP/servlet would be for type
checking.

Cheers, 
Nick




> 
> ----- Original Message -----
> From: "Rey Francois" <francois.rey@capco.com>
> To: <struts-dev@jakarta.apache.org>
> Sent: Wednesday, February 28, 2001 11:20 PM
> Subject: RE: Validating bean properties (WAS: Re: Stupd question aboutStru
> ts and EJB.)
> 
> 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