Levi Cook wrote:
>
> ----- 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.
I hate to keep being the PropertyEditor stick in the mud. :) But
a property editor is a huge amount of overhead just to do text
conversion... especially considering that there is already a FormBean
that can hold string versions of all of the form fields.
PropertyEditors are designed to take the value out of the bean and
hold it while it is being dynamically edited, then stored back into
the bean when editing has completed. This is nice for a GUI where
a component essentially gets its own value to play with until
editing has finished. It means that each property editor has its
own code to handle property change listeners, etc.. All of which
seems to be overkill in a request/response type of environment.
Furthermore, the complete property editor framework is designed to
have specific property editor classes associated with specific
object types. I've found this to be extremely limiting since it
requires a different property editor subclass for even slightly
different behavior. For example, if you have one type that allows
3 decimal places and another that allows only 2, you have to create
two separate property editor classes. Not much fun.
So, given that, the only way I can see to logically use
PropertyEditors in a web environment involves looking up the
appropriate editor, calling setAsText() and then immediately calling
getValue(). Seems wasteful when a specific conversion object could
boil it down to Object convertValue( String someText ). Not to
mention the fact that property editors don't even have to implement
the text methods.
In my opinion, a special set of interfaces designed for a web
environments needs is probably a better idea. A web server app
is very different than a Swing UI. In Swing, my gui components
usually know what kinds of objects they are dealing with and are
coded specifically for them. (For example, a calendar component
used to enter dates.) In the web world, form data always starts
as strings. The data is going to flow through a different kind
of pipeline that includes validation that would never have to be
done in a more robust UI.
I don't know what the real solution is, but my gut tells me it isn't
PropertyEditors. So I share the guilt. ;)
-Paul Speed
>
> 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
> >
> >
