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
implementation
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
functionality.
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.
L.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
