Good point Martin, I'm not that familiar with it yet, but do you know if the
jakarta-commons pool project would be of any help here??
Thanks in advance,
Levi Cook
----- Original Message -----
From: "Martin Cooper" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 23, 2001 9:51 PM
Subject: Re: server-side, java-based validation rules for struts..
> > 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);
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > >
> > > >
> > > > > >
> > > >
> > > >
> > >
>
>
>
