comments below...

----- Original Message -----
> From: "Jonathan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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.
> ;^>
>


Reply via email to