----- Original Message -----
From: "Paul Speed" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 25, 2001 12:42 PM
Subject: Re: Struts 1.1 TODO List -- Event and Listener Model
>
>
> Levi Cook wrote:
> >
> >
> > 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...
No problem, I'm a stick in the mud too..
So what defines huge? 4-5 years ago Java was doomed because carrying around
a runtime environment and placing its footprint into memory was considered
ridiculous. Similar arguments have been applied to single ancestor
inheritance models becuase every object in the system has all the attributes
and methods of the common ancestor, whether they need it or not. This can be
very wasteful of space and cpu time, right?? On one end these issues could
be a source of endless debate. On the other, we could funnel it away behind
a more request-response oriented interface.
> especially considering that there is already a FormBean
> that can hold string versions of all of the form fields.
Yet this is precisely where the rubber meets the road in our problem. The
challenge isn't in carrying around String representation, it lies within
validation, conversion, and possibly even runtime representation.
The real challenge, IMHO, is to find an abstraction that allows extension
but doesn't force an implementation. As long as we're at it, I don't think
its that bad of an idea to capitolize on a language established idiom that
developers might already be familiar with.
>
> 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.
Isn't this essentially the role an ActionForm plays where its typical
counterpart is a value-object from your problem domain? I see either case
simply as adapter's for producing objects your system knows about.
> 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.
Similar to "huge-overhead", overkill is pretty hard to quantify-- Some would
argue that J2EE containers are overkill, and in some contexts they are.
Their key value lies within the quality of abstraction they are able to
provide.
>
> 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.
When's a DateEditor not enough to handle dates-- Beyond that we can't
dictate how struts implementations should represent their data elements. In
one system it may be adequate to represent an email address with a String;
another might require a full-blown Email class.
>
> 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.
Its an interface, an implied contract.. If its defined and does nothing,
fine, that's the implementors decision and responsibility. For example, this
class compiles and I can new as many of these as I like, but I'm hard
pressed to find value in it, becuase the implementer chose not to define any
worthwhile behaviors.
public final class FooBar {}
>
> 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. ;)
>
I agree that this could very well turn out be the case, but all things being
equal, I see this as the next logical step for BeanUtils, PropertyUtils and
indirectly, the systems that rely on them.
-- Levi Cook
> -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
> > >
> > >
>
