You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jing Zhou <ji...@netspread.com> on 2002/04/10 23:42:13 UTC
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.
>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
Re: The Semantic of 'Cancel' Button
Posted by Jing Zhou <ji...@netspread.com>.
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" <jm...@telocity.com>
To: "Struts Developers List" <st...@jakarta.apache.org>
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:craigmcc@apache.org]
> > 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 <ji...@netspread.com>
> > > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > > To: Struts Developers List <st...@jakarta.apache.org>
> > > 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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: The Semantic of 'Cancel' Button
Posted by James Mitchell <jm...@telocity.com>.
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:craigmcc@apache.org]
> 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 <ji...@netspread.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: Struts Developers List <st...@jakarta.apache.org>
> > 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Semantic of 'Cancel' Button
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 10 Apr 2002, Jing Zhou wrote:
> Date: Wed, 10 Apr 2002 16:42:13 -0500
> From: Jing Zhou <ji...@netspread.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>