struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Topping" <topp...@digidemic.com>
Subject RE: RE: Unclear semantics on form use for "wizards"
Date Tue, 12 Nov 2002 02:53:42 GMT
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>


Mime
View raw message