> Slightly more exact mechanics for registering the listeners are:
> 1. Instantiate the form-bean
> 2. Instantiate zero to many listeners
> 3. Register each listener [...]
This sounds like it could be an expensive process to be going through on
each request. I think you'd want to arrange for the listeners to be
cacheable (by Struts) so that step 2 can be performed either at startup time
or on first "hit" for a given listener.
--
Martin Cooper
----- Original Message -----
From: "Cook, Levi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 8: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);
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > >
> > > > >
> > >
> > >
> >
