Thanks. I'll do what I can. -b
> -----Original Message----- > From: David Graham [mailto:dgraham1980@;hotmail.com] > Sent: Monday, November 11, 2002 9:46 PM > To: [EMAIL PROTECTED] > Subject: RE: RE: Unclear semantics on form use for "wizards" > > > If the documentation is vague, you can create a patch and post it to > bugzilla. I will apply any valid documentation patch ASAP. > > 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> > > -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
