An HOWTO would be nice =:0) http://jakarta.apache.org/struts/faqs/index.html
Over time, I'd like to condense the User Guide into an architechtural overview, and move the sections with signficiant code out, like "Accessing Relational Databases" out into HOWTOS. This will make it easier for people to scratch an itch without having to figure out where a section "fits" into the UserGuide. Eventually, I'd also like to have Developer Guides for each of the major packages, as we now have for the taglibs. This will give us a place to talk about how the classes interact that it outside the scope of a JavaDoc, but a little too general for a HOWTO. The nice part about the Developer Guides is that they are actually part of the JavaDocs (the overview.html). -Ted. 11/11/2002 9:53:42 PM, Brian Topping <[EMAIL PROTECTED]> wrote: >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" <struts- [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- [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>
