11/11/2002 2:26:20 PM, Jason Rosen <[EMAIL PROTECTED]> wrote: >Hmmm... I'll have to look into how reset() impacts unchecked checkboxes - I haven't had to deal with too many checkboxes in my project. > >Thanks for raising some issues to make me think about it, Craig.
Checkboxes on a session-scoped form is really the only reason we have a reset() in the first place. When the box is clear, the browser's don't send back the element at all, and so there is no way to turn it off again. Along the way, we got into the questionable habit of resetting everything whether it needed it or not. But for everything except a checkbox in session scope, there doesn't seem to be a value-add. In request scope, the form is usually newly created. In session scope, the initial property will "stick" until its overwritten (except for those nasty checkboxes). The practice of resetting everything has created a good number of support mails, since new developers copy the practice by rote, and then wonder why their session-scope properties disappear =:( Personally, I have been concerned by the current behavior of the DynaActionForm. Conventional ActionForms have a empty reset(), but DynaActionForms set everything back to the initial values. IMHO, that's a significant difference in behavior and violates the "backwardly compatibility" principle. It is what many developers do with their subclasses, but its not what Struts did out of the box. I haven't been able to study the code closely enough to offer an alternative. Ideally, it seems to me that whether to reset a field should be a property specified along with the initial value. But I haven't studied the code, and so I don't know if that's feasible. -Ted. -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
