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/
