Request scoped forms don't need to implement reset(). Ted has stated that Session scoped forms only need to reset checkboxes. If that's the case, maybe there is a symantically clearer method we could use. Many apps depend on the current reset behavior so this couldn't be changed before 2.0 if at all.

David






From: "Brian Topping" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Subject: RE: Unclear semantics on form use for "wizards"
Date: Mon, 11 Nov 2002 21:56:32 -0500

> -----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-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail


--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

Reply via email to