So at some point you will gat a handle to the ActionForm (read "bean") and
say:
actionForm.addVetoableChangeListener(String
propertyName,VetoableChangeListener listener)
or
actionForm.addVetoableChangeListener(VetoableChangeListener listener)
or
the third one which I dont totally understand. (please explain ;^> )
Also, please explain what the propertyName represents
The best thing about this is that the associations between beans and their
listeners is don all in one place (the xml file in our case). If you want
to add listeners to a bean just add them to the file.
One thing I may suggest is that maybe you dont need to be explicit with the
type of listeners, and just register listeners. I 'm not sure, however,
because I have not thought about the consequences of that yet.
----- Original Message -----
From: "Cook, Levi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 11:20 AM
Subject: RE: server-side, java-based validation rules for struts..
> 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);
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > >
> > > > >
> > >
> > >
> >
>