Great explanation Ted. I am interested in your implementation of the
ValueObjects. It appears as though you dont use the ActionForm as a value
object, but rather pass the ActionForm beans values on to the value object
after validating symantics in the Action. Is this true? I ask because I
have read 3-4 different ways to implement the value object, and I am
interested in what works best with struts. You remember the comment by
Bryan Field-Elliot? He wrote me with his implementation which he felt he
still had to work out some issues with hiding some data from other classes.
I then read an interesting idea at theserverside.com
http://www.theserverside.com/patterns/thread.jsp?thread_id=2722 and another
version http://www.theserverside.com/patterns/depbmp.jsp.
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 30, 2001 10:38 PM
Subject: Re: Bean philosophy
> Jonas Bjornerstedt wrote:
> > I see little reason (yet) why the ActionForm should be modeled as such.
>
> I think the keyword here is "yet". Much of the underlying Struts designs
> are based on trends and patterns that have yet to reach their logical
> conclusion.
>
> For example, future Java design tools are sure to fully support
> JavaBeans. Support for other structures, like hashtables, is likely to
> be less thorough. Another example is custom tags, which are a good thing
> now, but will be a truly tremendous thing when the visual HTML editors
> catch up with the Java 2 spec.
>
> Struts is also designed to work well with J2EE design patterns, which
> rely on JavaBeans. I construct both my form and model (or value) beans
> at the same time (using simple search and replace templates), and then
> extend the value beans to work with native types. Personally, I find it
> more convenient to be working with beans on both sides, rather than with
> a hashtable here and a JavaBean there.
>
> It is also very important to note that the ActionForm beans are just a
> means to an end. They exist as an adaptor between the HTML forms and the
> rest of your application. After the data has been captured, it should be
> handed to another object to handle the business-logic portion of your
> program. As such, they are usually only persistent for the life of a
> request, and as you say, should do little beside validating the input
> and converting the data for use by another object.
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
