The framework calls reset(), but its an extension point that the developer controls. For ActionForms, the developer has to affirmatively give reset() funcationality. For DynaActionForms, the developer can let the default behavior ride or override the extension point with any preferred behavior. But in either case, the framework is just calling a method. What the method does is up to the developer.
I generally don't use reset to clear any fields (except checkboxes in session scope), but I sometimes use it for other things, like snagging the locale object for use by other methods. I'm not crazy about the DynaActionForm's current behavior either. But, if it bothers me, I can override it. If I override it in a particularly clever way, I can propose the change and/or make my patch available to the community. But the framework is not foreclosing any opportunities. -Ted. 11/11/2002 9:56:32 PM, Brian Topping <[EMAIL PROTECTED]> wrote: >> -----Original Message----- >> From: Craig R. McClanahan [mailto:craigmcc@;apache.org] >> Subject: RE: Unclear semantics on form use for "wizards" >> >> The missing link for a multi-page form is some way to tie >> which page got >> submitted to the set of properties that live on that page >> (and therefore >> need to be reset. > >As David Graham said: "Interesting, but then you're creating a programming >language in XML. I think this logic should be in code." > >Occam's Razor (oh-so-trendy these days) would have it that the developer >knows best when a form needs to be reset and to let them call it. Clearly, >reset() needs to be called whenever a form is instantiated to get default >values, but it should not be called by the framework. If the form is in >request scope, the form will be created on Action invocation, semantically >implying reset(). If the form is session based and not a part of the >session, it is created and reset() is called. If the form is a part of the >session already, it is left alone. > >Thoughts? > >-b > >-- >To unsubscribe, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
