So you are saying that when an ActionForm is instantiated its associated
listener(s) get shoved in (read "registered") via a set method on the
ActionForm, and the Listener actually does the registering of itself in its
constructor or something.
So what you have is a bunch of ActionsForms with their listeners already
registered. Did I get it?
----- Original Message -----
From: "Levi Cook" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 11:44 AM
Subject: Re: server-side, java-based validation rules for struts..
> I guess that's the critical part, eh-- sorry for the hand-waving :)
>
> At this point, I see the Struts controller coordinating these "rules",
based
> on the contents of struts-config.xml:
> 1. Instantiation of our form-bean as needed (no real change here).
> 2. Instantiation of optional change-listeners* associated with our
form.
> (peek at the xml fragment below)
> 3. Now, it can register the change-listener (aka
> VetoableChangeListener), with our new form-bean.
> note: add<PropertyName>VetoableChangeListener
> & remove<PropertyName>VetoableChangeListener
> adhere to a naming pattern established by the JavaBeans spec.
> for more on this, see the last section on this page:
>
>
http://java.sun.com/docs/books/tutorial/javabeans/properties/constrained.htm
> l
>
> Assuming that this is all happened smoothly, which I think is pretty safe,
> that leaves the following main question:
> -- What happens when Struts begins to populate our action form?
>
> A. Nothing, our users suddendly started getting everything "right", so our
> Validators never complain about their input anymore.
> B. Our, the more probable route... our Validators start throwing
> PropertyVetoExceptions because our user's aren't any better at answering
> these questions than we are :)
>
> This point introduces the next responsibily I planned on handing the
> struts-controller: handling PropertyVetoExceptions. In short, I'd like it
to
> basically turn these exceptions into ActionErrors for us.
>
> Hope this sounds a little clearer, thanks for the feedback-- I think it
> greatly influences the ideas quality.
>
> Regards,
> Levi Cook
>
> > > <struts-config>
> > > <!-- etc.. -->
> > > <form-bean name="myCCForm" type="MyCCForm">
> > > <change-listener
> > > property="creditCard"
> > > type="CreditCardValidator"
> > > />
> > > </form-bean>
> > > <!-- etc.. -->
> > > </struts-config>
>
> ----- Original Message -----
> From: "Jonathan Asbell" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, June 21, 2001 4:42 AM
> Subject: Re: server-side, java-based validation rules for struts..
>
>
> > 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?
> >
> >
>
> > > 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);
> > > }
> > > }
> > > }
> > >
>
> > >
>
>
