I haven't had time yet to reorganize the code to
separate out validations into pure boolean validation
methods. The interface that is there now wasn't the
original one and has evolved over time. When I have
free time, I've normally focused on adding
functionality over reorganizing the source code.
David
--- Levi Cook <[EMAIL PROTECTED]> wrote:
> 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.
> > ;^>
> >
>
>
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
