struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurie Harper <>
Subject Re: Proposed DynaActionForm enhancement
Date Thu, 29 Sep 2005 20:48:01 GMT
The patch is actually modifying DynaActionFormClass -- the class that 
provides the factory method Struts uses to instantiate a DynaActionForm. 
There's on direct way to tell Struts to use a different implementation 
of this class. So, to do this as an extension, you have to:

1) configure a custom ActionFormConfig in the <form-beans> element, 
which will be used to construct all form bean configs

2) in that class, override getDynaClass to return a custom 
DynaActionFormClass implementation with this functionality

3) sub-class DyanActionForm and all its children, to expose 
setDynaClass() so it can be called by the custom DynaActionFormClass 

4) change all form bean definitions that use DyanActionForm or 
subclasses to reference the copies with exposed setDyanClass()

You end up with about half a dozen classes, most of them trivial, and 
have to configure every form bean differently to use the resulting 

As I say, a few minor tweaks would allow this to be dropped in as an 
extension so that all existing uses of DynaActionForm and friends would 
automatically get the added functionality.


Frank W. Zammetti wrote:
> Laurie, I'm curious... looking at the patch it seems like your only
> modifying DynaActionForm, correct?  If that's true, since you can set the
> class for an ActionForm in struts-config, what makes it so that you can't
> just set LauriesDynaActionForm instead of DynaActionForm?  Including CGLIB
> in your own app obviously isn't a problem, right?
> I'm only asking because I think it's an interesting enhancement, but I
> know the standard answer to things like this has been to make it an add-on
> rather than add it to core and I'm trying to understand what makes it
> non-trivial to go that route?

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

View raw message