struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hubert Rabago <>
Subject RE: Struts 1.1 ActionForm
Date Tue, 04 May 2004 06:33:35 GMT

Again, sharing my opinion on his points with you guys.

* "The DynaActionForm bloats up the Struts config file with the xml based
definition. This gets annoying as the Struts Config file grow larger."

I use FormDef, so this isn't a problem for me.

* "The DynaActionForm is not strongly typed as the ActionForm. This means
there is no compile time checking for the form fields. Detecting them at
runtime is painful and makes you go through redeployment."

ActionForm fields intended to hold form values are expected to use Strings,
and I still haven't had a reason to do otherwise.  If you get a typo after
your change and have to redeploy, well I don't mind living with that.  It's
not like its going to happen often enough to seriously make me prefer adding
class after class after class containing only string-ified version of
existing business objects.

* "ActionForm can be cleanly organized in packages as against the flat
organization in the Struts Config file."

I organize my action forms with the actions they interact with.  I don't have
submodules, but I still have a struts-config-group1.xml and
struts-config-group2.xml, each of which correspond to functions and features
I've grouped together, each containing only the declarations relevant to that

* "ActionForm were designed to act as a Firewall between HTTP and the Action
classes, i.e. isolate and encapsulate the HTTP request parameters from direct
use in Actions. With DynaActionForm, the property access is no different than
using request.getParameter(“..”)."

DynaForms still act as the firewall.  I can still pass around my DynaForm to
other objects without passing the request object.  DynaForms provide much
more than request.getParameter, especially when matched with Validator, and
it still has built-in support from Struts.

* "DynaActionForm construction at runtime requires a lot of Java Reflection
(Introspection) machinery that can be avoided."

The cost of this has been disputed several times.  I haven't seen any
numbers, so I can't say for sure how big or small the cost is, but I haven't
heard of a single case where a web app's performance was made considerably
better by reducing reflection operations after a form submission.  Design
changes are more likely to make a significant performance boost.  Besides,
the reflection-heavy BeanUtils methods are used for both DynaForms and
ActionForm classes, so I'm not sure where the savings, if any, will be.

* "Time savings from DynaActionForm is insignificant. It doesn’t take long
for today’s IDEs to generate getters and setters for the ActionForm
attributes. (Let us say that you made a silly typo in accessing the
DynaActionForm properties in the Action instance. It takes less time to
generate the getters and setters in the IDE than fixing your Action code and
redeploying your web application)" 

The issue isn't just with setters and getters.  You'll be adding a whole
class everytime you need a form.  Especially when you plug in something like
FormDef, I'm not sure why you'd choose a regular ActionForm for most CRUD


--- Matthias Wessendorf <> wrote:
> Eric,
> perhaps this is useful for you.
> cheers,
> matthias
> > -----Original Message-----
> > From: Eric Noel [] 
> > Sent: Tuesday, May 04, 2004 7:35 AM
> > To: Struts Users Mailing List
> > Subject: Struts 1.1 ActionForm
> > 
> > 
> > What is now the recommend technique for ActionForm, do we 
> > still have to 
> > use them? or just make use of the DynaActionForm instead and 
> > then create 
> > the corresponding Action or LookupDispatchAction?
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> > 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message