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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 20, 2001 10:02 PM
Subject: Re: server-side, java-based validation rules for struts..
> 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.
> > ;^>
> >
>
>
