Thanks,
David
From: "Brian Topping" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Subject: RE: RE: Unclear semantics on form use for "wizards"
Date: Mon, 11 Nov 2002 21:43:36 -0500
> -----Original Message-----
> From: Ted Husted [mailto:husted@;apache.org]
> Subject: Re: RE: Unclear semantics on form use for "wizards"
>
> 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.
Yes, most of my understanding of Struts so far is from the Javadoc, and I
would agree with this statement. IOW, I'm trying to come from the
perspective of what a user would come from had they simply read the
documentation and tried to solve one of their own problems.
I might add that this perspective is shaky: With heaps of respect to anyone
who takes the time to write documentation, any documentation, the Struts
documentation is extremely vague. I remember from six months or so back that
this is the meaning of reset() but I can't seem to find where I had learned
that from any longer. I saw it once, now I cannot find it. A developer
shouldn't have that problem; it should be in the documentation, and the
documentation forms the user contract on which the framework is extended.
When a contract is unclear, people find in it what they want to find rather
than what is actually there.
> 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 =:(
http://jakarta.apache.org/struts/userGuide/building_model.html makes
reference to the technique, and again, there used to be specific discussion
of correct use of reset(). But now, and I don't know how long for, reset()
is called every time through the controller, and the only way to stop it is
to catch the call in a subclass with a null implementation. It says nothing
to this effect, you just need to figure it out. It's bad. The javadoc
should eliminate the need to open the hood on the source files, and in the
alternate case should back each other up, not play "hot potato/needle in a
haystack" with the developer.
> 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.
I had offered a different alternative when I originally started this thread,
and if the volume of email on the subject, none authoritative, leads me to
the conclusion that this is a real problem.
Your observation here is astute. To sharpen it, as a framework, I believe
that Struts ought to implement what "most developers do with their
subclasses" with an end towards reducing the number of aggregate worldwide
subclasses (if that could only be a metric... ;) A correct framework is one
that _most_ developers will find perfectly adequate and without need to
subclass. In the middle of the spectrum is a framework component that
*everyone* needs to subclass, in which case the method/class is declared
'abstract' and is still "correct". What is incorrect is when the majority of
the developers who subclass the framework do it in exactly the same way iff
they need to do it. In that case, the framework should be extended to handle
that case so that it no longer needs to be subclassed.
Having said all that, what you are saying here with the difference between
Dyna and conventional is key. There should be no difference, making the
current implementation broken if the values are getting reset to the defaults
on every Action invocation. I personally believe that there needs to be a
way to get the default values back, and that seems to be by calling reset(),
which then leads to the fact that reset should not be called except when the
form is being created. This means my suggested fix is wrong as well, that
reset should only be called as a step of form instantiation -- implied with a
form that is request-scoped, and not called every time as it is today.
-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>
