Yes, the end result is ActionForms with Listeners registered prior to the
ActionServlet populating our form with the users request values.
Slightly more exact mechanics for registering the listeners are:
1. Instantiate the form-bean
2. Instantiate zero to many listeners
3. Register each listener using one of following bean method naming
conventions:
add<PropertyName>VetoableChangeListener(VetoableChangeListener listener)
addVetoableChangeListener(String propertyName, VetoableChangeListener
listener)
addVetoableChangeListener(VetoableChangeListener listener)
A key abstraction here, is that neither object ever has an explicit
reference to the other. Said another way this provides loose coupling
between our action forms and their listeners. This supports the struts as a
framework concept by allowing the following:
1. The number (zero to many) of listeners may be unknown at compile-time,
and can vary throughout run-time.
2. Listener and form objects neet to be loosely coupled becuase we have no
way of predicting all the Listeners (eg. Validations) users could be
interested in.
Abstraction sure seems difficult to explain sometimes, thanks again for
helping me refine my explanation.
Levi
> -----Original Message-----
> From: Jonathan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 21, 2001 9:10 AM
> To: [EMAIL PROTECTED]
> Subject: Re: server-side, java-based validation rules for struts..
>
>
> 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);
> > > > }
> > > > }
> > > > }
> > > >
> >
> > > >
> >
> >
>
