struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Asbell" <jasb...@i-2000.com>
Subject Re: server-side, java-based validation rules for struts..
Date Thu, 21 Jun 2001 11:42:51 GMT
Levi, you lost me somewhere in your explanation from ....."now have to
account for interacting with Struts-- That's where I see
java.bean.VetoableChangeListener........."

What are you passing to whom, and where are you instantiating and
registering things?


----- Original Message -----
From: "Levi Cook" <levicook@papajo.com>
To: <struts-dev@jakarta.apache.org>
Sent: Wednesday, June 20, 2001 10:02 PM
Subject: Re: server-side, java-based validation rules for struts..


> comments below...
>
> ----- Original Message -----
> > From: "Jonathan" <jasbell@i-2000.com>
> > To: <struts-dev@jakarta.apache.org>
> > Sent: Wednesday, June 20, 2001 12:55 PM
> > Subject: Re: server-side, java-based validation rules for struts..
> >
> > Hello Levi.
> > I read your comment yesterday and went and read about constrained
> properties
> > and bound properties in section 7.4 of the java beans spec link you
sent.
> I
> > think people didnt answer because you didnt speak enough about what you
> are
> > suggesting in the context of what has already been developed.  I think
the
> > "veto" idea is interesting, but it doesnt replace what is being
developed,
> > but rather only adds to it.
>
> I agree, this proposal is not a replacement for the things being developed
> to date.
> The main point is that the JavaBeans approach provides an established,
> proven
> framework for pluggable validation rules.
>
> That said, its certainly feasible that adopting this approach could ripple
> into existing work. In general, I think it will promote looser coupling
> between struts objects and validation rules.
>
> For instance, let's consider Dave W's Validator.validateCreditCard method.
>
> Its signature goes something like this:
>
> 0:  public void validateCreditCard(
> 1:      java.lang.Object bean,
> 2:      ValidatorAction va,
> 3:      Field field,
> 4:      org.apache.struts.action.ActionErrors errors,
> 5:      javax.servlet.http.HttpServletRequest request,
> 6:      javax.servlet.ServletContext application
> 7:    )
>
> Now, I like Dave's work quite a bit, and I don't want to sound like a
> critic.
> Nonetheless, there are several opportunities to reduce coupling in this
> method.
>
> I would refactor validateCreditCard into a simple utility method.
> eg. public static boolean isCreditCard(String ccNumber) {..}
>
> Once that's in place (and tested :), I now have to account for interacting
> with
> Struts-- That's where I see java.bean.VetoableChangeListener helping out.
> Basically I'd suggest doing the following (in whatever order you prefer):
>
> 1. Create my actionform
> 2. Create my VetoableChangeListener
> 3. Add my form & its change-listener/validator to struts-config
>
> >From there, I would expect Struts to handle the rest.. Where the rest is:
> 1. Call addCreditCardVetoableChangeListener() passing in a new
>     instance of CreditCardValidator.
> 2. Catch any PropertyVetoExceptions throw by setCreditCard
>     and turn them into ActionErrors.
> 3. Return the control to the user w/ there actual input values
>     and a sensible message indicating how to correct the err.
>
> public MyCCForm extends ActionForm {
>   public setCreditCard(String newCreditCard) throws PropertyVetoException
{
>     vcs.fireVetoableChange(CC_PROP_NAME, creditCard, newCreditCard);
>     creditCard= newCreditCard;
>   }
>   public void addCreditCardVetoableChangeListener(VetoableChangeListener
> lsnr) {
>     vcs.addVetoableChangeListener(CC_PROP_NAME, lsnr);
>   }
>   private String creditCard;
>   private static final String CC_PROP_NAME= "creditCard";
>   private VetoableChangeSupport vcs= new VetoableChangeSupport(this);
> }
>
> public class CreditCardValidator implements VetoableChangeListener {
>   public void vetoableChange(PropertyChangeEvent evt)
>     throws PropertyVetoException
>   {
>     String creditCard= null;
>     try {
>       creditCard= (String) evt.getNewValue();
>     }
>     finally {
>       if(StringValidator.isCreditCard(creditCard) == false)
>         throw new PropertyVetoException("some.msg.key", evt);
>     }
>   }
> }
>
> <struts-config>
>   <!-- etc.. -->
>   <form-bean name="myCCForm" type="MyCCForm">
>     <change-listener
>         property="creditCard"
>         type="CreditCardValidator"
>     />
>   </form-bean>
>   <!-- etc.. -->
> </struts-config>
>
> >  It could be added of course.  But the validations that have been
> developed
> > and discussed thus far go much farther than what the beans offer.
>
> The fact that they do go farther is one of the reasons I felt it was
> necessary
> find a slightly more abstract approach. Said another way, concrete
> validations
> are great (especially the commonly required validation like "is s an email
> address")
> however, we will never be able to supply all
> At this stage, I'm not claiming its an adequate, or appropriate
abstaction,
> but I definitly feel its a candidate.
>
> > We have been trying to actually build (and some have like Dave
> Winderfeldt)
> > a bunch of validations for common problems like
> > credit cards, emails, money etc.  In fact the java beans spec doesnt
> address
> > what is involved in validating an e-mail ,phone number etc., but rather
a
> > general concept in implementing something you have validated via some
> > algorithm etc.etc.  Check out some of the various posts about validation
> and
> > you will see what I mean.
> > ;^>
> >
>
>


Mime
View raw message