struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <hus...@apache.org>
Subject Re: RE: RE: Unclear semantics on form use for "wizards"
Date Tue, 12 Nov 2002 16:11:56 GMT
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 <topping@digidemic.com> 
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: struts-dev@jakarta.apache.org
>> 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" <topping@digidemic.com>
>> >Reply-To: "Struts Developers List" <struts-
dev@jakarta.apache.org>
>> >To: "Struts Developers List" <struts-dev@jakarta.apache.org>
>> >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>
>
>




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


Mime
View raw message