DO NOT REPLY [Bug 14669] New: - reset() in DynaActionForm act the same as ActionForm

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14669>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14669

reset() in DynaActionForm act the same as ActionForm

           Summary: reset() in DynaActionForm act the same as ActionForm
           Product: Struts
           Version: Nightly Build
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Blocker
          Priority: Other
         Component: Controller
        AssignedTo: struts-dev@jakarta.apache.org
        ReportedBy: topping@digidemic.com


A very difficult to manage problem with DynaActionForm is that the reset() 
method does not act the same as the reset() in ActionForm.  Because the 
controller calls reset() on a form associated with an Action every time it is 
entered and DynaActionForm.reset() clobbers all the values, a DynaActionForm is 
effectively erased between calls where an ActionForm is not.  The controller 
was written to call reset() every time, and for purposes of compatibility the 
struts-dev consensus is that this cannot be changed.  

This is not a trivial problem that is simply solved by subclassing the 
DynaActionForm and introducing a null reset() function, as this blocks access 
to the worthwhile code that sets up the form values from the XML configuration.

The correct solution to this is to entirely move the code in 
DynaActionForm.reset() that is responsible for setting the values to the XML 
configuration default into a separate initFromXML() (or somesuch) call and have 
that call called from the constructor (or somewhere in the DynaActionForm 
instantiation chain.)  It needs to be a separately accessible call so that the 
developer can call it when they *actually* want the values to be replaced.  
It's true that some developers will subclass DynaActionForm and create a reset
() function that simply calls super.initFromXML(), but far less than the ones 
that do not wish for the values to be clobbered every time.  It's worth noting 
that the correct use of a DynaActionForm that should be reset every time is to 
have it in request scope, which effectively resets the form every time by 
destroying it.

I am happy to submit patches for this if they will be considered, but the fix 
is faster than it took to type all this.  I'm blocked on implementation of a 
number of use cases until this is fixed, because the cheezy hacks required to 
work around this aren't something that I'm really relishing adding to my 
otherwise clean application.

Thanks for reading this.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>