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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>