----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 22, 2001 7:23 PM
Subject: RE: Struts 1.1 TODO List -- Event and Listener Model
>
>
> On Fri, 22 Jun 2001, Cook, Levi wrote:
>
> > Ahhh, now I follow what you were saying.
> >
> > I think both event dispatching mechanisms exist becuase they provide
support
> > for semantically separate issues. The first form is notification that
> > something "interesting" just happened. The second form is the prevention
of
> > placing an object into an invalid or inconsistent state.
> >
> > Actually, this really goes back to the JavaBean specification where
bound &
> > constrained properties are defined. This ultimately leads me to question
> > whether its appropriate, and beneficial to treat ActionForms as
JavaBeans
> > (aka. java's component architecture for building modular software
> > components)?
> >
> > The benefits for treating forms as Beans would generally be described
as:
> > 1) are usable by programming tools
> > 2) follow a standard naming convention
> > 3) have a conscise public interface
> > 4) helps keep the learning curve shallow
> >
> > To bean or not to bean, that is the question :)
> >
>
> An important reason that ActionForm classes should (at least) conform to
> the standard naming conventions is that the automatic population of
> properties from request parameters relies on this. Otherwise, the bean
> will not be recognized as having a property that matches.
>
The automatic population of properties from request parameters is indeed a
major benefit of being bean-like. My thinking is that we should extend the
notion of being bean-like into support for full-fledged beans, and
capitolize on yet more of these types benefits. In my mind, the JavaBeans
framework goes a long way towards addressing a great number of the issues I
see recurringly posted to this list.
Some of this issues include:
Validation: Vetoable change listeners, through loose typing can be
transformed, but Struts into ActionErrors.
Conversion: Property editors getAsText & setAsText- all request attributes
are strings, turning them into full-fledged java objects is why this
infrastructure exists.
Enumarated Properties: Property editors getTags can return a set of
allowable values-- If we chose to make our html:xxx tags sensistive to this,
we could simplify our jsp's.
It possibly eliminates the apparent interface duplication between our
concrete ActionForm's and domain specific value-beans. Ultimately, this also
allows more of your code to be used outside struts, maybe more importantly,
it may lower the cost of entry and allow people to adopt struts simply by
wiring in their existing code.
Hopefully, I'll soon start showing more code to demonstrate these
possibilities :) Maybe then I will feel a little less guilty about
suggesting where things should go... Does anyone have a couple extra hours
per day I can borrow??
Regards,
Levi Cook
>
> However, Struts currently does not deal gracefully with things like a veto
> exception on a constrained property. We'll need to decide what we want to
> do about those.
>
> > Any other ideas or opinions on this?
> >
> > -- Levi
> >
>
> Craig
>
>
