Thanks Craig and James. I can accept the original design thinking. Raising the question is because I thought skipping over populating form beans in canceling process is a *common* behavior, and therefore it should be implemented in base classes, instead of in sub classes.
The 'Are-you-sure-yes-no' dialog right after 'Cancel' button is a *special* scenario. I observed a lot of 'Are-you-sure-yes-no' dialogs right after 'Exit' button or 'Save' button, and haven't found any real application giving me a 'Are-you-sure-yes-no' dialog after 'Cancel' button. So I thought it is more a semantic problem rather than an application specific problem. I agree with Craig on the backwards compatibility issue and like the ideas to add an attribute to the CancelTag to allow both scenarios. Thanks, Jing ----- Original Message ----- From: "James Mitchell" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, April 10, 2002 10:05 PM Subject: RE: The Semantic of 'Cancel' Button > Sorry if I appear overly aggressive, but this reminds me of an argument I > had with a former project manager (note the word *former* because he didn't > last too long) > > If you look at the source code > http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/src/ > (or) the developer guide > http://jakarta.apache.org/struts/struts-html.html#cancel > (or) the taglib documentation > http://jakarta.apache.org/struts/struts-html.html#cancel > it clearly states that using the html:cancel will render an <input > type="submit" name="......and so on and so forth. > > Therefore it is up to you (the developer) to decide what to do inside your > action class. If you have decided to give the user one last chance (Are you > sure? Yes/No) You certainly don't want your auto-magically populated form > bean to be "kicked-to-the-curb" (sorry, I'm from Georgia). > > On the other hand. If you want to avoid the overhead (however little it > might be) of having your form populated, then you could create a separate > html:form on the page and stick your cancel where the sun don't > shi.....(sorry, getting off track here).....have your cancel submit its own > form so that struts has nothing to populate. You even get the added bonus > of specifying a different action so you don't have to figure it out in (what > would have been) the original action class. > > This issue is really specific to someone's application, not really about > struts. > > Good Luck > JM > > (I never did like that project manager anyway) > > > > -----Original Message----- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, April 10, 2002 10:31 PM > > To: Struts Developers List > > Subject: Re: The Semantic of 'Cancel' Button > > > > > > > > > > On Wed, 10 Apr 2002, Jing Zhou wrote: > > > > > Date: Wed, 10 Apr 2002 16:42:13 -0500 > > > From: Jing Zhou <[EMAIL PROTECTED]> > > > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > > > To: Struts Developers List <[EMAIL PROTECTED]> > > > Subject: The Semantic of 'Cancel' Button > > > > > > In STRUTS, the 'Cancel' button (the html tag) will populate > > > the form beans, if there is one, and skip over the validation. > > > The question is why STRUTS need to populate the form beans > > > When a 'Cancel' button signal is received. > > > > > > > The original thinking for this design is that "cancellation is in the eyes > > of the beholder" -- it's the action that decides whether the user really > > cancelled or not. In addition, you couldn't do an "are you sure" page > > that redisplayed the partially filled out form unless the form bean was > > populated. > > > > I can see your reasoning for the opposite behavior as well -- but changing > > it now would also be a backwards compatibility issue. At best, we could > > make it a configurable behavior. (Or, you can subclass ActionServlet in > > 1.0 or RequestProcessor in 1.1 and achieve that behavior for yourself by > > overriding a single method.) > > > > Craig > > > > > > > >From my past experiences on UI development, if the 'Cancel' button > > > is clicked in a dialog, it will close the dialog and do NOT apply > > > any changes to the underlying data buffer, in STRUTS contexts, > > > the data buffer is the form beans. If the 'Cancel' button > > > is shown on a html page, when it is clicked, it will take the users > > > to a different page, which is the first page of a wizard like app, > > > or some index page. So in either cases, STRUTS do not need > > > to populate the form beans. > > > > > > More important is that when user click the 'Cancel' button, she > > > means to discard whatever data on the screen. But STRUTS > > > populate the discarded data into the working form beans, so > > > it creates possibility that developers may use wrong data > > > in the form beans and make further logic decisions. Actually, > > > all the developers need to know is the Action.isCancelled(), > > > that is enough, in my opinion. > > > > > > It gets another problem if the application would like to > > > re-produce the screen before the 'Cancel' button is clicked. > > > The re-produced screen will show up with the data which > > > she means to discard in the previous clicking of the 'Cancel' > > > button in the current STRUTS implementation. > > > > > > In all scenarios I think STRUTS should skip over the population > > > of the form beans when the 'Cancel' button is clicked. > > > Could anyone clarify this issue? It is possible I am missing > > > some other scenarios where populating form beans are > > > necessary when clicking the 'Cancel' button. > > > > > > Thanks, > > > > > > Jing > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
