You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rob <bs...@insightoutsight.com.au> on 2003/07/17 01:57:05 UTC
dificult problem, preventing population (repost)
I have the following scenario occuring.
I have a form with several fields on it (the fields are sourced to a
collection in an
ActionForm). I have a button that allows the removal of fields from the
form (items
from the collection). If a user removes a field from the form and then
double
submits/clicks back and reloads then an exception is thrown from
BeanUtils.populate()
because it attempts to take details from the (now removed field) and
populate it into
the object that is stored in the position it was located in the
collection. Obviously
since the collection is now smaller this results in an
IndexOutOfBoundsException.
Is there any way to examine the transaction token from the form prior to
the form
bean being populated and then avoid population of the form bean if the
token is not
valid?
Help with this problem would be greatly appreciated.
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Adam Hardy" <ah...@cyberspaceroad.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Thursday, July 17, 2003 3:50 AM
Subject: Re: dificult problem, preventing population (repost)
> I'm sure a quick look in the source code would give you what you want -
> try looking at isTokenValue() in Action.java
If I understand the original question correctly, it is too late to check the
token using isTokenValid() in action class. Then you have to
consider something at an *early* time.
>
> Jing Zhou wrote:
> > ----- Original Message -----
> > From: "Rob" <bs...@insightoutsight.com.au>
> > To: <st...@jakarta.apache.org>
> > Sent: Wednesday, July 16, 2003 6:57 PM
> > Subject: dificult problem, preventing population (repost)
> >
> >
> >
> >>I have the following scenario occuring.
> >>
> >>I have a form with several fields on it (the fields are sourced to a
> >>collection in an
> >>ActionForm). I have a button that allows the removal of fields from the
> >>form (items
> >>from the collection). If a user removes a field from the form and then
> >>double
> >>submits/clicks back and reloads then an exception is thrown from
> >>BeanUtils.populate()
> >>because it attempts to take details from the (now removed field) and
> >>populate it into
> >>the object that is stored in the position it was located in the
> >>collection. Obviously
> >>since the collection is now smaller this results in an
> >>IndexOutOfBoundsException.
> >>
> >>Is there any way to examine the transaction token from the form prior to
> >>the form
> >>bean being populated and then avoid population of the form bean if the
> >>token is not
> >>valid?
> >
> >
> > There are three steps involved when using transaction token:
> > 1) Setting token;
> > 2) Checking token;
> > 3) Resetting token;
> >
> > It looks right if we could perform the second step in a subclass of
> > the RequestProcessor so that the token is checked before form
> > bean population. But where do we put the first step and the
> > third step? If we put them in an action class, then how does
> > the derived request processor know when it should check
> > the token? If we put them all in the derived request processor,
> > that is not correct either, because they are business logics not
> > applicable to every action mappings.
> >
> > The real *bad* guy is the browser's Back button your users
> > are using. The browser's tool bar and address bar are
> > intended to help load document oriented resources. They
> > are useless for application oriented resources in our
> > concepts. One good practice I saw is to turn off the
> > tool bar and address bar. It gives you the look and feel
> > of *real* applications. Of course, you must provide navigation
> > buttons for your applications.
> >
> > Sometimes, business people would say they *want* the
> > tool bar or address bar (actually they do not know what
> > really they want in many times :-) In such case, you have
> > to find a way to disable the Back button. If you try the
> > JavaScript location.replace() in the second page, it will
> > forget the past - no back any more.
> >
> > As you see, it is not easy to get a *correct* solution and
> > my suggestion may not be applicable to your case. But I
> > am interested in any further thoughts.
> >
> >
> >
> >>Help with this problem would be greatly appreciated.
> >>
> >>Rob
> >>
> >
> >
> > Jing
> > Netspread Carrier
> > http://www.netspread.com
> >
> >
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Sandeep Takhar <sa...@yahoo.com>.
I guess the issue is the same one you mentioned
earlier which is that we have to know which action is
preparing the token and which one is checking it. To
do this generically means adding something to
action-mapping, but since this is not an option
currently then I don't think it should be since the
developers of struts would have added it if this is
the right spot.
sandeep
--- Jing Zhou <ji...@netspread.com> wrote:
>
> ----- Original Message -----
> From: "Sandeep Takhar" <sa...@yahoo.com>
> To: "Struts Users Mailing List"
> <st...@jakarta.apache.org>; "Jing
> Zhou" <ji...@netspread.com>
> Sent: Friday, July 18, 2003 12:37 PM
> Subject: Re: dificult problem, preventing population
> (repost)
>
>
> > I suppose you would get the page expired if you
> are
> > using noCache...
> >
> > So what do people do? Do they just right their
> own
> > stuff. On the application that we have built over
> the
> > last year - we have opened another window and with
> the
> > parameters passed to the open window we have
> removed
> > the menu lines. However if the user hits
> backspace in
> > certain situations, this is equivalent to pressing
> the
> > back button.
> >
> > I know the struts workflow extension proposes a
> > solution. But what are people doing?? I guess
> that
> > is the original question, but the more I think
> about
> > it the more I'm curious to know what the options
> are.
> >
> > I suppose what was mentioned before about using
> > mappings and subclassing ActionMapping may be the
> only
> > way? (This is essentially what workflow does)
>
> One possible way is to add a method prepareExecute()
> in the action base class. After the RequestProcessor
> obtains the action mapping and before populates the
> form bean, it invokes the prepareExecute() method on
> the action class. If it finds anything wrong after
> the
> prepareExecute() call, it throws an exception.
>
> This way would return the logics to handle the
> tokens
> back to action developers. Is this reasonable?
> Any other ideas?
>
> >
> > sandeep
>
> Jing
>
> > --- Jing Zhou <ji...@netspread.com> wrote:
> > > Hi, Sandeep,
> > >
> > > There is no clean solution to this problem, not
> > > only in Struts but also in many others ...
> > >
> > > I wish there could be a simple way to disable
> > > the Back button. But browser vendors would
> > > say once it is disabled, who is responsible
> > > to enable it. There should be some better
> > > algorithm for this problem.
> > >
> > > Jing
> > >
> > > ----- Original Message -----
> > > From: "Sandeep Takhar"
> <sa...@yahoo.com>
> > > To: "Struts Users Mailing List"
> > > <st...@jakarta.apache.org>; "Jing
> > > Zhou" <ji...@netspread.com>
> > > Sent: Thursday, July 17, 2003 12:35 PM
> > > Subject: Re: dificult problem, preventing
> population
> > > (repost)
> > >
> > >
> > > > Ah... I see what you mean.
> > > >
> > > > Yes, not thinking that clearly, but I have not
> > > done it
> > > > either so that is my excuse...
> > > >
> > > > So I think that to make this too complicated
> is
> > > not
> > > > good.
> > > >
> > > > So the original problem states that when
> pressing
> > > the
> > > > back button that they get back to the screen.
> I
> > > am
> > > > wondering right now that when the press the
> back
> > > > button they should be in the "submit" state
> again
> > > and
> > > > the token check should occur again?
> > >
> > > If the previous page is a submitted page, you
> would
> > > get
> > > "Page has Expired ...". If the previous page is
> > > retrieved
> > > by an http get method, you would do a "GET"
> again.
> > >
> > > >
> > > > Sometimes I wish I could pick up the phone and
> > > sort
> > > > these type of things out because I'm probably
> > > missing
> > > > something again.
> > > >
> > > > sandeep
> > > >
> > > >
> > > > --- Jing Zhou <ji...@netspread.com> wrote:
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Sandeep Takhar"
> > > <sa...@yahoo.com>
> > > > > To: "Struts Users Mailing List"
> > > > > <st...@jakarta.apache.org>
> > > > > Sent: Thursday, July 17, 2003 7:49 AM
> > > > > Subject: Re: dificult problem, preventing
> > > population
> > > > > (repost)
> > > > >
> > > > >
> > > > > > I think he meant isTokenValid().
> > > > > >
> > > > > > Also the form tag will create the token
> and
> > > you
> > > > > can
> > > > > > look at it in the source.
> > > > > >
> > > > > > You can check the token higher if you want
> > > (before
> > > > > > population) by placing it in one of these
> > > methods
> > > > > on
> > > > > > the requestProcessor..
> > > > >
> > > > > My analysis shows we can't simply check the
> > > token
> > > > > at processPreProcess method, as an example.
> > > Because
> > > > > the RequestProcessor doesn't known when it
> > > should
> > > > > check and when it should not.
> > > > >
> > > > > It could involve more complicated logics
> than
> > > what
> > > > > we can imagine to get it done here, although
> > > > > it is not all impossible.
> > > > >
> > > > > If someone would like to layout a detail
> > > algorithm
> > > > > here, I believe some parameters in action
> > > mappings
> > > > > should be used. But that is easier to create
> > > *holes*
> > > > > than ... That's why it is a *difficult*
> problem
> > > :-)
> > > > >
> > > > > Jing
> > > > >
> > > > > >
> > > > > > (not sure logistically which one has the
> > > request
> > > > > > signature & more importantly which one
> makes
> > > > > sense)...
> > > > > >
> > > > > > This is in order:
> > > > > >
> > > > > > processMultipart
> > > > > > processPath
> > > > > > processLocale
> > > > > > processContent
> > > > > > processNoCache
> > > > > > processPreProcess * looks promising
> > > > > > processMapping
> > > > > > processRoles
> > > > > > processActionForm
> > > > > > processPopulate
> > > > > >
> > > > > > 1st and 3rd are normally done in the
> action
> > > class.
> > > > >
> > > > > > One that handles the display and the one
> that
> > > you
> > > > > are
> > > > > > submitting to.
> > > > > >
> > > > > > sandeep
> > > > > > --- Adam Hardy
> > > <ah...@cyberspaceroad.com>
> > > > > > wrote:
> > > > > > > I'm sure a quick look in the source code
> > > would
> > > > > give
> > > > > > > you what you want -
> > > > > > > try looking at isTokenValue() in
> Action.java
> > > > > > >
> > > > > > > Jing Zhou wrote:
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Rob"
> <bs...@insightoutsight.com.au>
> > > > > > > > To: <st...@jakarta.apache.org>
> > > > > > > > Sent: Wednesday, July 16, 2003 6:57 PM
> > > > > > > > Subject: dificult problem, preventing
> > > > > population
> > > > > > > (repost)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >>I have the following scenario
> occuring.
> > > > > > > >>
> > > > > > > >>I have a form with several fields on
> it
> > > (the
> > > > > > > fields are sourced to a
> > > > > > > >>collection in an
> > > > > > > >>ActionForm). I have a button that
> allows
> > > the
> > > > > > > removal of fields from the
> > > > > > > >>form (items
> > > > > > > >>from the collection). If a user
> removes a
> > > > > field
> > > > > > > from the form and then
> > > > > > > >>double
> > > > > > > >>submits/clicks back and reloads then
> an
> > > > > exception
> > > > > > > is thrown from
> > > > > > > >>BeanUtils.populate()
> > > > > > > >>because it attempts to take details
> from
> > > the
> > > > > (now
> > > > > > > removed field) and
> > > > > > > >>populate it into
> > > > > > > >>the object that is stored in the
> position
> > > it
> > > > > was
> > > > > > > located in the
> > > > > > > >>collection. Obviously
> > > > > > > >>since the collection is now smaller
> this
> > > > > results
> > > > > > > in an
> > > > > > > >>IndexOutOfBoundsException.
> > > > > > > >>
> > > > > > > >>Is there any way to examine the
> > > transaction
> > > > > token
> > > > > > > from the form prior to
> > > > > > > >>the form
> > > > > > > >>bean being populated and then avoid
> > > population
> > > > > of
> > > > > > > the form bean if the
> > > > > > > >>token is not
> > > > > > > >>valid?
> > > > > > > >
> > > > > > > >
> > > > > > > > There are three steps involved when
> using
> > > > > > > transaction token:
> > > > > > > > 1) Setting token;
> > > > > > > > 2) Checking token;
> > > > > > > > 3) Resetting token;
> > > > > > > >
> > > > > > > > It looks right if we could perform the
> > > second
> > > > > step
> > > > > > > in a subclass of
> > > > > > > > the RequestProcessor so that the token
> is
> > > > > checked
> > > > > > > before form
> > > > > > > > bean population. But where do we put
> the
> > > first
> > > > > > > step and the
> > > > > > > > third step? If we put them in an
> action
> > > class,
> > > > > > > then how does
> > > > > > > > the derived request processor know
> when it
> > > > > should
> > > > > > > check
> > > > > > > > the token? If we put them all in the
> > > derived
> > > > > > > request processor,
> > > > > > > > that is not correct either, because
> they
> > > are
> > > > > > > business logics not
> > > > > > > > applicable to every action mappings.
> > > > > > > >
> > > > > > > > The real *bad* guy is the browser's
> Back
> > > > > button
> > > > > > > your users
> > > > > > > > are using. The browser's tool bar and
> > > address
> > > > > bar
> > > > > > > are
> > > > > > > > intended to help load document
> oriented
> > > > > resources.
> > > > > > > They
> > > > > > > > are useless for application oriented
> > > resources
> > > > > in
> > > > > > > our
> > > > > > > > concepts. One good practice I saw is
> to
> > > turn
> > > > > off
> > > > > > > the
> > > > > > > > tool bar and address bar. It gives you
> the
> > > > > look
> > > > > > > and feel
> > > > > > > > of *real* applications. Of course, you
> > > must
> > > > > > > provide navigation
> > > > > > > > buttons for your applications.
> > > > > > > >
> > > > > > > > Sometimes, business people would say
> they
> > > > > *want*
> > > > > > > the
> > > > > > > > tool bar or address bar (actually they
> do
> > > not
> > > > > know
> > > > > > > what
> > > > > > > > really they want in many times :-) In
> such
> > > > > case,
> > > > > > > you have
> > > > > > > > to find a way to disable the Back
> button.
> > > If
> > > > > you
> > > > > > > try the
> > > > > > > > JavaScript location.replace() in the
> > > second
> > > > > page,
> > > > > > > it will
> > > > > > > > forget the past - no back any more.
> > > > > > > >
> > > > > > > > As you see, it is not easy to get a
> > > *correct*
> > > > > > > solution and
> > > > > > > > my suggestion may not be applicable to
> > > your
> > > > > case.
> > > > > > > But I
> > > > > > > > am interested in any further thoughts.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >>Help with this problem would be
> greatly
> > > > > > > appreciated.
> > > > > > > >>
> > > > > > > >>Rob
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > > Jing
> > > > > > > > Netspread Carrier
> > > > > > > > http://www.netspread.com
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>>---------------------------------------------------------------------
> > > > > > > >>To unsubscribe, e-mail:
> > > > > > >
> struts-user-unsubscribe@jakarta.apache.org
> > > > > > > >>For additional commands, e-mail:
> > > > > > > struts-user-help@jakarta.apache.org
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> > > > > > >
> struts-user-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail:
> > > > > > > struts-user-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> > > > > > >
> struts-user-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
> > > > > > > struts-user-help@jakarta.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > > __________________________________
> > > > > > Do you Yahoo!?
> > > > > > SBC Yahoo! DSL - Now only $29.95 per
> month!
> > > > > > http://sbc.yahoo.com
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > > > > struts-user-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > > struts-user-help@jakarta.apache.org
> > > > >
> > > >
> > > >
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > SBC Yahoo! DSL - Now only $29.95 per month!
> > > > http://sbc.yahoo.com
> > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > struts-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > struts-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > struts-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month!
> > http://sbc.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Sandeep Takhar" <sa...@yahoo.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>; "Jing
Zhou" <ji...@netspread.com>
Sent: Friday, July 18, 2003 12:37 PM
Subject: Re: dificult problem, preventing population (repost)
> I suppose you would get the page expired if you are
> using noCache...
>
> So what do people do? Do they just right their own
> stuff. On the application that we have built over the
> last year - we have opened another window and with the
> parameters passed to the open window we have removed
> the menu lines. However if the user hits backspace in
> certain situations, this is equivalent to pressing the
> back button.
>
> I know the struts workflow extension proposes a
> solution. But what are people doing?? I guess that
> is the original question, but the more I think about
> it the more I'm curious to know what the options are.
>
> I suppose what was mentioned before about using
> mappings and subclassing ActionMapping may be the only
> way? (This is essentially what workflow does)
One possible way is to add a method prepareExecute()
in the action base class. After the RequestProcessor
obtains the action mapping and before populates the
form bean, it invokes the prepareExecute() method on
the action class. If it finds anything wrong after the
prepareExecute() call, it throws an exception.
This way would return the logics to handle the tokens
back to action developers. Is this reasonable?
Any other ideas?
>
> sandeep
Jing
> --- Jing Zhou <ji...@netspread.com> wrote:
> > Hi, Sandeep,
> >
> > There is no clean solution to this problem, not
> > only in Struts but also in many others ...
> >
> > I wish there could be a simple way to disable
> > the Back button. But browser vendors would
> > say once it is disabled, who is responsible
> > to enable it. There should be some better
> > algorithm for this problem.
> >
> > Jing
> >
> > ----- Original Message -----
> > From: "Sandeep Takhar" <sa...@yahoo.com>
> > To: "Struts Users Mailing List"
> > <st...@jakarta.apache.org>; "Jing
> > Zhou" <ji...@netspread.com>
> > Sent: Thursday, July 17, 2003 12:35 PM
> > Subject: Re: dificult problem, preventing population
> > (repost)
> >
> >
> > > Ah... I see what you mean.
> > >
> > > Yes, not thinking that clearly, but I have not
> > done it
> > > either so that is my excuse...
> > >
> > > So I think that to make this too complicated is
> > not
> > > good.
> > >
> > > So the original problem states that when pressing
> > the
> > > back button that they get back to the screen. I
> > am
> > > wondering right now that when the press the back
> > > button they should be in the "submit" state again
> > and
> > > the token check should occur again?
> >
> > If the previous page is a submitted page, you would
> > get
> > "Page has Expired ...". If the previous page is
> > retrieved
> > by an http get method, you would do a "GET" again.
> >
> > >
> > > Sometimes I wish I could pick up the phone and
> > sort
> > > these type of things out because I'm probably
> > missing
> > > something again.
> > >
> > > sandeep
> > >
> > >
> > > --- Jing Zhou <ji...@netspread.com> wrote:
> > > >
> > > > ----- Original Message -----
> > > > From: "Sandeep Takhar"
> > <sa...@yahoo.com>
> > > > To: "Struts Users Mailing List"
> > > > <st...@jakarta.apache.org>
> > > > Sent: Thursday, July 17, 2003 7:49 AM
> > > > Subject: Re: dificult problem, preventing
> > population
> > > > (repost)
> > > >
> > > >
> > > > > I think he meant isTokenValid().
> > > > >
> > > > > Also the form tag will create the token and
> > you
> > > > can
> > > > > look at it in the source.
> > > > >
> > > > > You can check the token higher if you want
> > (before
> > > > > population) by placing it in one of these
> > methods
> > > > on
> > > > > the requestProcessor..
> > > >
> > > > My analysis shows we can't simply check the
> > token
> > > > at processPreProcess method, as an example.
> > Because
> > > > the RequestProcessor doesn't known when it
> > should
> > > > check and when it should not.
> > > >
> > > > It could involve more complicated logics than
> > what
> > > > we can imagine to get it done here, although
> > > > it is not all impossible.
> > > >
> > > > If someone would like to layout a detail
> > algorithm
> > > > here, I believe some parameters in action
> > mappings
> > > > should be used. But that is easier to create
> > *holes*
> > > > than ... That's why it is a *difficult* problem
> > :-)
> > > >
> > > > Jing
> > > >
> > > > >
> > > > > (not sure logistically which one has the
> > request
> > > > > signature & more importantly which one makes
> > > > sense)...
> > > > >
> > > > > This is in order:
> > > > >
> > > > > processMultipart
> > > > > processPath
> > > > > processLocale
> > > > > processContent
> > > > > processNoCache
> > > > > processPreProcess * looks promising
> > > > > processMapping
> > > > > processRoles
> > > > > processActionForm
> > > > > processPopulate
> > > > >
> > > > > 1st and 3rd are normally done in the action
> > class.
> > > >
> > > > > One that handles the display and the one that
> > you
> > > > are
> > > > > submitting to.
> > > > >
> > > > > sandeep
> > > > > --- Adam Hardy
> > <ah...@cyberspaceroad.com>
> > > > > wrote:
> > > > > > I'm sure a quick look in the source code
> > would
> > > > give
> > > > > > you what you want -
> > > > > > try looking at isTokenValue() in Action.java
> > > > > >
> > > > > > Jing Zhou wrote:
> > > > > > > ----- Original Message -----
> > > > > > > From: "Rob" <bs...@insightoutsight.com.au>
> > > > > > > To: <st...@jakarta.apache.org>
> > > > > > > Sent: Wednesday, July 16, 2003 6:57 PM
> > > > > > > Subject: dificult problem, preventing
> > > > population
> > > > > > (repost)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >>I have the following scenario occuring.
> > > > > > >>
> > > > > > >>I have a form with several fields on it
> > (the
> > > > > > fields are sourced to a
> > > > > > >>collection in an
> > > > > > >>ActionForm). I have a button that allows
> > the
> > > > > > removal of fields from the
> > > > > > >>form (items
> > > > > > >>from the collection). If a user removes a
> > > > field
> > > > > > from the form and then
> > > > > > >>double
> > > > > > >>submits/clicks back and reloads then an
> > > > exception
> > > > > > is thrown from
> > > > > > >>BeanUtils.populate()
> > > > > > >>because it attempts to take details from
> > the
> > > > (now
> > > > > > removed field) and
> > > > > > >>populate it into
> > > > > > >>the object that is stored in the position
> > it
> > > > was
> > > > > > located in the
> > > > > > >>collection. Obviously
> > > > > > >>since the collection is now smaller this
> > > > results
> > > > > > in an
> > > > > > >>IndexOutOfBoundsException.
> > > > > > >>
> > > > > > >>Is there any way to examine the
> > transaction
> > > > token
> > > > > > from the form prior to
> > > > > > >>the form
> > > > > > >>bean being populated and then avoid
> > population
> > > > of
> > > > > > the form bean if the
> > > > > > >>token is not
> > > > > > >>valid?
> > > > > > >
> > > > > > >
> > > > > > > There are three steps involved when using
> > > > > > transaction token:
> > > > > > > 1) Setting token;
> > > > > > > 2) Checking token;
> > > > > > > 3) Resetting token;
> > > > > > >
> > > > > > > It looks right if we could perform the
> > second
> > > > step
> > > > > > in a subclass of
> > > > > > > the RequestProcessor so that the token is
> > > > checked
> > > > > > before form
> > > > > > > bean population. But where do we put the
> > first
> > > > > > step and the
> > > > > > > third step? If we put them in an action
> > class,
> > > > > > then how does
> > > > > > > the derived request processor know when it
> > > > should
> > > > > > check
> > > > > > > the token? If we put them all in the
> > derived
> > > > > > request processor,
> > > > > > > that is not correct either, because they
> > are
> > > > > > business logics not
> > > > > > > applicable to every action mappings.
> > > > > > >
> > > > > > > The real *bad* guy is the browser's Back
> > > > button
> > > > > > your users
> > > > > > > are using. The browser's tool bar and
> > address
> > > > bar
> > > > > > are
> > > > > > > intended to help load document oriented
> > > > resources.
> > > > > > They
> > > > > > > are useless for application oriented
> > resources
> > > > in
> > > > > > our
> > > > > > > concepts. One good practice I saw is to
> > turn
> > > > off
> > > > > > the
> > > > > > > tool bar and address bar. It gives you the
> > > > look
> > > > > > and feel
> > > > > > > of *real* applications. Of course, you
> > must
> > > > > > provide navigation
> > > > > > > buttons for your applications.
> > > > > > >
> > > > > > > Sometimes, business people would say they
> > > > *want*
> > > > > > the
> > > > > > > tool bar or address bar (actually they do
> > not
> > > > know
> > > > > > what
> > > > > > > really they want in many times :-) In such
> > > > case,
> > > > > > you have
> > > > > > > to find a way to disable the Back button.
> > If
> > > > you
> > > > > > try the
> > > > > > > JavaScript location.replace() in the
> > second
> > > > page,
> > > > > > it will
> > > > > > > forget the past - no back any more.
> > > > > > >
> > > > > > > As you see, it is not easy to get a
> > *correct*
> > > > > > solution and
> > > > > > > my suggestion may not be applicable to
> > your
> > > > case.
> > > > > > But I
> > > > > > > am interested in any further thoughts.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >>Help with this problem would be greatly
> > > > > > appreciated.
> > > > > > >>
> > > > > > >>Rob
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > > Jing
> > > > > > > Netspread Carrier
> > > > > > > http://www.netspread.com
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >>---------------------------------------------------------------------
> > > > > > >>To unsubscribe, e-mail:
> > > > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > > >>For additional commands, e-mail:
> > > > > > struts-user-help@jakarta.apache.org
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> > > > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
> > > > > > struts-user-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > struts-user-help@jakarta.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > __________________________________
> > > > > Do you Yahoo!?
> > > > > SBC Yahoo! DSL - Now only $29.95 per month!
> > > > > http://sbc.yahoo.com
> > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > struts-user-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > > struts-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > > struts-user-help@jakarta.apache.org
> > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > SBC Yahoo! DSL - Now only $29.95 per month!
> > > http://sbc.yahoo.com
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > struts-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Sandeep Takhar <sa...@yahoo.com>.
I suppose you would get the page expired if you are
using noCache...
So what do people do? Do they just right their own
stuff. On the application that we have built over the
last year - we have opened another window and with the
parameters passed to the open window we have removed
the menu lines. However if the user hits backspace in
certain situations, this is equivalent to pressing the
back button.
I know the struts workflow extension proposes a
solution. But what are people doing?? I guess that
is the original question, but the more I think about
it the more I'm curious to know what the options are.
I suppose what was mentioned before about using
mappings and subclassing ActionMapping may be the only
way? (This is essentially what workflow does)
sandeep
--- Jing Zhou <ji...@netspread.com> wrote:
> Hi, Sandeep,
>
> There is no clean solution to this problem, not
> only in Struts but also in many others ...
>
> I wish there could be a simple way to disable
> the Back button. But browser vendors would
> say once it is disabled, who is responsible
> to enable it. There should be some better
> algorithm for this problem.
>
> Jing
>
> ----- Original Message -----
> From: "Sandeep Takhar" <sa...@yahoo.com>
> To: "Struts Users Mailing List"
> <st...@jakarta.apache.org>; "Jing
> Zhou" <ji...@netspread.com>
> Sent: Thursday, July 17, 2003 12:35 PM
> Subject: Re: dificult problem, preventing population
> (repost)
>
>
> > Ah... I see what you mean.
> >
> > Yes, not thinking that clearly, but I have not
> done it
> > either so that is my excuse...
> >
> > So I think that to make this too complicated is
> not
> > good.
> >
> > So the original problem states that when pressing
> the
> > back button that they get back to the screen. I
> am
> > wondering right now that when the press the back
> > button they should be in the "submit" state again
> and
> > the token check should occur again?
>
> If the previous page is a submitted page, you would
> get
> "Page has Expired ...". If the previous page is
> retrieved
> by an http get method, you would do a "GET" again.
>
> >
> > Sometimes I wish I could pick up the phone and
> sort
> > these type of things out because I'm probably
> missing
> > something again.
> >
> > sandeep
> >
> >
> > --- Jing Zhou <ji...@netspread.com> wrote:
> > >
> > > ----- Original Message -----
> > > From: "Sandeep Takhar"
> <sa...@yahoo.com>
> > > To: "Struts Users Mailing List"
> > > <st...@jakarta.apache.org>
> > > Sent: Thursday, July 17, 2003 7:49 AM
> > > Subject: Re: dificult problem, preventing
> population
> > > (repost)
> > >
> > >
> > > > I think he meant isTokenValid().
> > > >
> > > > Also the form tag will create the token and
> you
> > > can
> > > > look at it in the source.
> > > >
> > > > You can check the token higher if you want
> (before
> > > > population) by placing it in one of these
> methods
> > > on
> > > > the requestProcessor..
> > >
> > > My analysis shows we can't simply check the
> token
> > > at processPreProcess method, as an example.
> Because
> > > the RequestProcessor doesn't known when it
> should
> > > check and when it should not.
> > >
> > > It could involve more complicated logics than
> what
> > > we can imagine to get it done here, although
> > > it is not all impossible.
> > >
> > > If someone would like to layout a detail
> algorithm
> > > here, I believe some parameters in action
> mappings
> > > should be used. But that is easier to create
> *holes*
> > > than ... That's why it is a *difficult* problem
> :-)
> > >
> > > Jing
> > >
> > > >
> > > > (not sure logistically which one has the
> request
> > > > signature & more importantly which one makes
> > > sense)...
> > > >
> > > > This is in order:
> > > >
> > > > processMultipart
> > > > processPath
> > > > processLocale
> > > > processContent
> > > > processNoCache
> > > > processPreProcess * looks promising
> > > > processMapping
> > > > processRoles
> > > > processActionForm
> > > > processPopulate
> > > >
> > > > 1st and 3rd are normally done in the action
> class.
> > >
> > > > One that handles the display and the one that
> you
> > > are
> > > > submitting to.
> > > >
> > > > sandeep
> > > > --- Adam Hardy
> <ah...@cyberspaceroad.com>
> > > > wrote:
> > > > > I'm sure a quick look in the source code
> would
> > > give
> > > > > you what you want -
> > > > > try looking at isTokenValue() in Action.java
> > > > >
> > > > > Jing Zhou wrote:
> > > > > > ----- Original Message -----
> > > > > > From: "Rob" <bs...@insightoutsight.com.au>
> > > > > > To: <st...@jakarta.apache.org>
> > > > > > Sent: Wednesday, July 16, 2003 6:57 PM
> > > > > > Subject: dificult problem, preventing
> > > population
> > > > > (repost)
> > > > > >
> > > > > >
> > > > > >
> > > > > >>I have the following scenario occuring.
> > > > > >>
> > > > > >>I have a form with several fields on it
> (the
> > > > > fields are sourced to a
> > > > > >>collection in an
> > > > > >>ActionForm). I have a button that allows
> the
> > > > > removal of fields from the
> > > > > >>form (items
> > > > > >>from the collection). If a user removes a
> > > field
> > > > > from the form and then
> > > > > >>double
> > > > > >>submits/clicks back and reloads then an
> > > exception
> > > > > is thrown from
> > > > > >>BeanUtils.populate()
> > > > > >>because it attempts to take details from
> the
> > > (now
> > > > > removed field) and
> > > > > >>populate it into
> > > > > >>the object that is stored in the position
> it
> > > was
> > > > > located in the
> > > > > >>collection. Obviously
> > > > > >>since the collection is now smaller this
> > > results
> > > > > in an
> > > > > >>IndexOutOfBoundsException.
> > > > > >>
> > > > > >>Is there any way to examine the
> transaction
> > > token
> > > > > from the form prior to
> > > > > >>the form
> > > > > >>bean being populated and then avoid
> population
> > > of
> > > > > the form bean if the
> > > > > >>token is not
> > > > > >>valid?
> > > > > >
> > > > > >
> > > > > > There are three steps involved when using
> > > > > transaction token:
> > > > > > 1) Setting token;
> > > > > > 2) Checking token;
> > > > > > 3) Resetting token;
> > > > > >
> > > > > > It looks right if we could perform the
> second
> > > step
> > > > > in a subclass of
> > > > > > the RequestProcessor so that the token is
> > > checked
> > > > > before form
> > > > > > bean population. But where do we put the
> first
> > > > > step and the
> > > > > > third step? If we put them in an action
> class,
> > > > > then how does
> > > > > > the derived request processor know when it
> > > should
> > > > > check
> > > > > > the token? If we put them all in the
> derived
> > > > > request processor,
> > > > > > that is not correct either, because they
> are
> > > > > business logics not
> > > > > > applicable to every action mappings.
> > > > > >
> > > > > > The real *bad* guy is the browser's Back
> > > button
> > > > > your users
> > > > > > are using. The browser's tool bar and
> address
> > > bar
> > > > > are
> > > > > > intended to help load document oriented
> > > resources.
> > > > > They
> > > > > > are useless for application oriented
> resources
> > > in
> > > > > our
> > > > > > concepts. One good practice I saw is to
> turn
> > > off
> > > > > the
> > > > > > tool bar and address bar. It gives you the
> > > look
> > > > > and feel
> > > > > > of *real* applications. Of course, you
> must
> > > > > provide navigation
> > > > > > buttons for your applications.
> > > > > >
> > > > > > Sometimes, business people would say they
> > > *want*
> > > > > the
> > > > > > tool bar or address bar (actually they do
> not
> > > know
> > > > > what
> > > > > > really they want in many times :-) In such
> > > case,
> > > > > you have
> > > > > > to find a way to disable the Back button.
> If
> > > you
> > > > > try the
> > > > > > JavaScript location.replace() in the
> second
> > > page,
> > > > > it will
> > > > > > forget the past - no back any more.
> > > > > >
> > > > > > As you see, it is not easy to get a
> *correct*
> > > > > solution and
> > > > > > my suggestion may not be applicable to
> your
> > > case.
> > > > > But I
> > > > > > am interested in any further thoughts.
> > > > > >
> > > > > >
> > > > > >
> > > > > >>Help with this problem would be greatly
> > > > > appreciated.
> > > > > >>
> > > > > >>Rob
> > > > > >>
> > > > > >
> > > > > >
> > > > > > Jing
> > > > > > Netspread Carrier
> > > > > > http://www.netspread.com
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>>---------------------------------------------------------------------
> > > > > >>To unsubscribe, e-mail:
> > > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > >>For additional commands, e-mail:
> > > > > struts-user-help@jakarta.apache.org
> > > > > >>
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > > > > struts-user-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > > struts-user-help@jakarta.apache.org
> > > > >
> > > >
> > > >
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > SBC Yahoo! DSL - Now only $29.95 per month!
> > > > http://sbc.yahoo.com
> > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > struts-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > struts-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > struts-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month!
> > http://sbc.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Jing Zhou <ji...@netspread.com>.
Hi, Sandeep,
There is no clean solution to this problem, not
only in Struts but also in many others ...
I wish there could be a simple way to disable
the Back button. But browser vendors would
say once it is disabled, who is responsible
to enable it. There should be some better
algorithm for this problem.
Jing
----- Original Message -----
From: "Sandeep Takhar" <sa...@yahoo.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>; "Jing
Zhou" <ji...@netspread.com>
Sent: Thursday, July 17, 2003 12:35 PM
Subject: Re: dificult problem, preventing population (repost)
> Ah... I see what you mean.
>
> Yes, not thinking that clearly, but I have not done it
> either so that is my excuse...
>
> So I think that to make this too complicated is not
> good.
>
> So the original problem states that when pressing the
> back button that they get back to the screen. I am
> wondering right now that when the press the back
> button they should be in the "submit" state again and
> the token check should occur again?
If the previous page is a submitted page, you would get
"Page has Expired ...". If the previous page is retrieved
by an http get method, you would do a "GET" again.
>
> Sometimes I wish I could pick up the phone and sort
> these type of things out because I'm probably missing
> something again.
>
> sandeep
>
>
> --- Jing Zhou <ji...@netspread.com> wrote:
> >
> > ----- Original Message -----
> > From: "Sandeep Takhar" <sa...@yahoo.com>
> > To: "Struts Users Mailing List"
> > <st...@jakarta.apache.org>
> > Sent: Thursday, July 17, 2003 7:49 AM
> > Subject: Re: dificult problem, preventing population
> > (repost)
> >
> >
> > > I think he meant isTokenValid().
> > >
> > > Also the form tag will create the token and you
> > can
> > > look at it in the source.
> > >
> > > You can check the token higher if you want (before
> > > population) by placing it in one of these methods
> > on
> > > the requestProcessor..
> >
> > My analysis shows we can't simply check the token
> > at processPreProcess method, as an example. Because
> > the RequestProcessor doesn't known when it should
> > check and when it should not.
> >
> > It could involve more complicated logics than what
> > we can imagine to get it done here, although
> > it is not all impossible.
> >
> > If someone would like to layout a detail algorithm
> > here, I believe some parameters in action mappings
> > should be used. But that is easier to create *holes*
> > than ... That's why it is a *difficult* problem :-)
> >
> > Jing
> >
> > >
> > > (not sure logistically which one has the request
> > > signature & more importantly which one makes
> > sense)...
> > >
> > > This is in order:
> > >
> > > processMultipart
> > > processPath
> > > processLocale
> > > processContent
> > > processNoCache
> > > processPreProcess * looks promising
> > > processMapping
> > > processRoles
> > > processActionForm
> > > processPopulate
> > >
> > > 1st and 3rd are normally done in the action class.
> >
> > > One that handles the display and the one that you
> > are
> > > submitting to.
> > >
> > > sandeep
> > > --- Adam Hardy <ah...@cyberspaceroad.com>
> > > wrote:
> > > > I'm sure a quick look in the source code would
> > give
> > > > you what you want -
> > > > try looking at isTokenValue() in Action.java
> > > >
> > > > Jing Zhou wrote:
> > > > > ----- Original Message -----
> > > > > From: "Rob" <bs...@insightoutsight.com.au>
> > > > > To: <st...@jakarta.apache.org>
> > > > > Sent: Wednesday, July 16, 2003 6:57 PM
> > > > > Subject: dificult problem, preventing
> > population
> > > > (repost)
> > > > >
> > > > >
> > > > >
> > > > >>I have the following scenario occuring.
> > > > >>
> > > > >>I have a form with several fields on it (the
> > > > fields are sourced to a
> > > > >>collection in an
> > > > >>ActionForm). I have a button that allows the
> > > > removal of fields from the
> > > > >>form (items
> > > > >>from the collection). If a user removes a
> > field
> > > > from the form and then
> > > > >>double
> > > > >>submits/clicks back and reloads then an
> > exception
> > > > is thrown from
> > > > >>BeanUtils.populate()
> > > > >>because it attempts to take details from the
> > (now
> > > > removed field) and
> > > > >>populate it into
> > > > >>the object that is stored in the position it
> > was
> > > > located in the
> > > > >>collection. Obviously
> > > > >>since the collection is now smaller this
> > results
> > > > in an
> > > > >>IndexOutOfBoundsException.
> > > > >>
> > > > >>Is there any way to examine the transaction
> > token
> > > > from the form prior to
> > > > >>the form
> > > > >>bean being populated and then avoid population
> > of
> > > > the form bean if the
> > > > >>token is not
> > > > >>valid?
> > > > >
> > > > >
> > > > > There are three steps involved when using
> > > > transaction token:
> > > > > 1) Setting token;
> > > > > 2) Checking token;
> > > > > 3) Resetting token;
> > > > >
> > > > > It looks right if we could perform the second
> > step
> > > > in a subclass of
> > > > > the RequestProcessor so that the token is
> > checked
> > > > before form
> > > > > bean population. But where do we put the first
> > > > step and the
> > > > > third step? If we put them in an action class,
> > > > then how does
> > > > > the derived request processor know when it
> > should
> > > > check
> > > > > the token? If we put them all in the derived
> > > > request processor,
> > > > > that is not correct either, because they are
> > > > business logics not
> > > > > applicable to every action mappings.
> > > > >
> > > > > The real *bad* guy is the browser's Back
> > button
> > > > your users
> > > > > are using. The browser's tool bar and address
> > bar
> > > > are
> > > > > intended to help load document oriented
> > resources.
> > > > They
> > > > > are useless for application oriented resources
> > in
> > > > our
> > > > > concepts. One good practice I saw is to turn
> > off
> > > > the
> > > > > tool bar and address bar. It gives you the
> > look
> > > > and feel
> > > > > of *real* applications. Of course, you must
> > > > provide navigation
> > > > > buttons for your applications.
> > > > >
> > > > > Sometimes, business people would say they
> > *want*
> > > > the
> > > > > tool bar or address bar (actually they do not
> > know
> > > > what
> > > > > really they want in many times :-) In such
> > case,
> > > > you have
> > > > > to find a way to disable the Back button. If
> > you
> > > > try the
> > > > > JavaScript location.replace() in the second
> > page,
> > > > it will
> > > > > forget the past - no back any more.
> > > > >
> > > > > As you see, it is not easy to get a *correct*
> > > > solution and
> > > > > my suggestion may not be applicable to your
> > case.
> > > > But I
> > > > > am interested in any further thoughts.
> > > > >
> > > > >
> > > > >
> > > > >>Help with this problem would be greatly
> > > > appreciated.
> > > > >>
> > > > >>Rob
> > > > >>
> > > > >
> > > > >
> > > > > Jing
> > > > > Netspread Carrier
> > > > > http://www.netspread.com
> > > > >
> > > > >
> > > >
> > >
> >
> >>---------------------------------------------------------------------
> > > > >>To unsubscribe, e-mail:
> > > > struts-user-unsubscribe@jakarta.apache.org
> > > > >>For additional commands, e-mail:
> > > > struts-user-help@jakarta.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > struts-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > struts-user-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > > struts-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > > struts-user-help@jakarta.apache.org
> > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > SBC Yahoo! DSL - Now only $29.95 per month!
> > > http://sbc.yahoo.com
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > struts-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Sandeep Takhar <sa...@yahoo.com>.
Ah... I see what you mean.
Yes, not thinking that clearly, but I have not done it
either so that is my excuse...
So I think that to make this too complicated is not
good.
So the original problem states that when pressing the
back button that they get back to the screen. I am
wondering right now that when the press the back
button they should be in the "submit" state again and
the token check should occur again?
Sometimes I wish I could pick up the phone and sort
these type of things out because I'm probably missing
something again.
sandeep
--- Jing Zhou <ji...@netspread.com> wrote:
>
> ----- Original Message -----
> From: "Sandeep Takhar" <sa...@yahoo.com>
> To: "Struts Users Mailing List"
> <st...@jakarta.apache.org>
> Sent: Thursday, July 17, 2003 7:49 AM
> Subject: Re: dificult problem, preventing population
> (repost)
>
>
> > I think he meant isTokenValid().
> >
> > Also the form tag will create the token and you
> can
> > look at it in the source.
> >
> > You can check the token higher if you want (before
> > population) by placing it in one of these methods
> on
> > the requestProcessor..
>
> My analysis shows we can't simply check the token
> at processPreProcess method, as an example. Because
> the RequestProcessor doesn't known when it should
> check and when it should not.
>
> It could involve more complicated logics than what
> we can imagine to get it done here, although
> it is not all impossible.
>
> If someone would like to layout a detail algorithm
> here, I believe some parameters in action mappings
> should be used. But that is easier to create *holes*
> than ... That's why it is a *difficult* problem :-)
>
> Jing
>
> >
> > (not sure logistically which one has the request
> > signature & more importantly which one makes
> sense)...
> >
> > This is in order:
> >
> > processMultipart
> > processPath
> > processLocale
> > processContent
> > processNoCache
> > processPreProcess * looks promising
> > processMapping
> > processRoles
> > processActionForm
> > processPopulate
> >
> > 1st and 3rd are normally done in the action class.
>
> > One that handles the display and the one that you
> are
> > submitting to.
> >
> > sandeep
> > --- Adam Hardy <ah...@cyberspaceroad.com>
> > wrote:
> > > I'm sure a quick look in the source code would
> give
> > > you what you want -
> > > try looking at isTokenValue() in Action.java
> > >
> > > Jing Zhou wrote:
> > > > ----- Original Message -----
> > > > From: "Rob" <bs...@insightoutsight.com.au>
> > > > To: <st...@jakarta.apache.org>
> > > > Sent: Wednesday, July 16, 2003 6:57 PM
> > > > Subject: dificult problem, preventing
> population
> > > (repost)
> > > >
> > > >
> > > >
> > > >>I have the following scenario occuring.
> > > >>
> > > >>I have a form with several fields on it (the
> > > fields are sourced to a
> > > >>collection in an
> > > >>ActionForm). I have a button that allows the
> > > removal of fields from the
> > > >>form (items
> > > >>from the collection). If a user removes a
> field
> > > from the form and then
> > > >>double
> > > >>submits/clicks back and reloads then an
> exception
> > > is thrown from
> > > >>BeanUtils.populate()
> > > >>because it attempts to take details from the
> (now
> > > removed field) and
> > > >>populate it into
> > > >>the object that is stored in the position it
> was
> > > located in the
> > > >>collection. Obviously
> > > >>since the collection is now smaller this
> results
> > > in an
> > > >>IndexOutOfBoundsException.
> > > >>
> > > >>Is there any way to examine the transaction
> token
> > > from the form prior to
> > > >>the form
> > > >>bean being populated and then avoid population
> of
> > > the form bean if the
> > > >>token is not
> > > >>valid?
> > > >
> > > >
> > > > There are three steps involved when using
> > > transaction token:
> > > > 1) Setting token;
> > > > 2) Checking token;
> > > > 3) Resetting token;
> > > >
> > > > It looks right if we could perform the second
> step
> > > in a subclass of
> > > > the RequestProcessor so that the token is
> checked
> > > before form
> > > > bean population. But where do we put the first
> > > step and the
> > > > third step? If we put them in an action class,
> > > then how does
> > > > the derived request processor know when it
> should
> > > check
> > > > the token? If we put them all in the derived
> > > request processor,
> > > > that is not correct either, because they are
> > > business logics not
> > > > applicable to every action mappings.
> > > >
> > > > The real *bad* guy is the browser's Back
> button
> > > your users
> > > > are using. The browser's tool bar and address
> bar
> > > are
> > > > intended to help load document oriented
> resources.
> > > They
> > > > are useless for application oriented resources
> in
> > > our
> > > > concepts. One good practice I saw is to turn
> off
> > > the
> > > > tool bar and address bar. It gives you the
> look
> > > and feel
> > > > of *real* applications. Of course, you must
> > > provide navigation
> > > > buttons for your applications.
> > > >
> > > > Sometimes, business people would say they
> *want*
> > > the
> > > > tool bar or address bar (actually they do not
> know
> > > what
> > > > really they want in many times :-) In such
> case,
> > > you have
> > > > to find a way to disable the Back button. If
> you
> > > try the
> > > > JavaScript location.replace() in the second
> page,
> > > it will
> > > > forget the past - no back any more.
> > > >
> > > > As you see, it is not easy to get a *correct*
> > > solution and
> > > > my suggestion may not be applicable to your
> case.
> > > But I
> > > > am interested in any further thoughts.
> > > >
> > > >
> > > >
> > > >>Help with this problem would be greatly
> > > appreciated.
> > > >>
> > > >>Rob
> > > >>
> > > >
> > > >
> > > > Jing
> > > > Netspread Carrier
> > > > http://www.netspread.com
> > > >
> > > >
> > >
> >
>
>>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail:
> > > struts-user-unsubscribe@jakarta.apache.org
> > > >>For additional commands, e-mail:
> > > struts-user-help@jakarta.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > struts-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > struts-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > struts-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month!
> > http://sbc.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Sandeep Takhar" <sa...@yahoo.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Thursday, July 17, 2003 7:49 AM
Subject: Re: dificult problem, preventing population (repost)
> I think he meant isTokenValid().
>
> Also the form tag will create the token and you can
> look at it in the source.
>
> You can check the token higher if you want (before
> population) by placing it in one of these methods on
> the requestProcessor..
My analysis shows we can't simply check the token
at processPreProcess method, as an example. Because
the RequestProcessor doesn't known when it should
check and when it should not.
It could involve more complicated logics than what
we can imagine to get it done here, although
it is not all impossible.
If someone would like to layout a detail algorithm
here, I believe some parameters in action mappings
should be used. But that is easier to create *holes*
than ... That's why it is a *difficult* problem :-)
Jing
>
> (not sure logistically which one has the request
> signature & more importantly which one makes sense)...
>
> This is in order:
>
> processMultipart
> processPath
> processLocale
> processContent
> processNoCache
> processPreProcess * looks promising
> processMapping
> processRoles
> processActionForm
> processPopulate
>
> 1st and 3rd are normally done in the action class.
> One that handles the display and the one that you are
> submitting to.
>
> sandeep
> --- Adam Hardy <ah...@cyberspaceroad.com>
> wrote:
> > I'm sure a quick look in the source code would give
> > you what you want -
> > try looking at isTokenValue() in Action.java
> >
> > Jing Zhou wrote:
> > > ----- Original Message -----
> > > From: "Rob" <bs...@insightoutsight.com.au>
> > > To: <st...@jakarta.apache.org>
> > > Sent: Wednesday, July 16, 2003 6:57 PM
> > > Subject: dificult problem, preventing population
> > (repost)
> > >
> > >
> > >
> > >>I have the following scenario occuring.
> > >>
> > >>I have a form with several fields on it (the
> > fields are sourced to a
> > >>collection in an
> > >>ActionForm). I have a button that allows the
> > removal of fields from the
> > >>form (items
> > >>from the collection). If a user removes a field
> > from the form and then
> > >>double
> > >>submits/clicks back and reloads then an exception
> > is thrown from
> > >>BeanUtils.populate()
> > >>because it attempts to take details from the (now
> > removed field) and
> > >>populate it into
> > >>the object that is stored in the position it was
> > located in the
> > >>collection. Obviously
> > >>since the collection is now smaller this results
> > in an
> > >>IndexOutOfBoundsException.
> > >>
> > >>Is there any way to examine the transaction token
> > from the form prior to
> > >>the form
> > >>bean being populated and then avoid population of
> > the form bean if the
> > >>token is not
> > >>valid?
> > >
> > >
> > > There are three steps involved when using
> > transaction token:
> > > 1) Setting token;
> > > 2) Checking token;
> > > 3) Resetting token;
> > >
> > > It looks right if we could perform the second step
> > in a subclass of
> > > the RequestProcessor so that the token is checked
> > before form
> > > bean population. But where do we put the first
> > step and the
> > > third step? If we put them in an action class,
> > then how does
> > > the derived request processor know when it should
> > check
> > > the token? If we put them all in the derived
> > request processor,
> > > that is not correct either, because they are
> > business logics not
> > > applicable to every action mappings.
> > >
> > > The real *bad* guy is the browser's Back button
> > your users
> > > are using. The browser's tool bar and address bar
> > are
> > > intended to help load document oriented resources.
> > They
> > > are useless for application oriented resources in
> > our
> > > concepts. One good practice I saw is to turn off
> > the
> > > tool bar and address bar. It gives you the look
> > and feel
> > > of *real* applications. Of course, you must
> > provide navigation
> > > buttons for your applications.
> > >
> > > Sometimes, business people would say they *want*
> > the
> > > tool bar or address bar (actually they do not know
> > what
> > > really they want in many times :-) In such case,
> > you have
> > > to find a way to disable the Back button. If you
> > try the
> > > JavaScript location.replace() in the second page,
> > it will
> > > forget the past - no back any more.
> > >
> > > As you see, it is not easy to get a *correct*
> > solution and
> > > my suggestion may not be applicable to your case.
> > But I
> > > am interested in any further thoughts.
> > >
> > >
> > >
> > >>Help with this problem would be greatly
> > appreciated.
> > >>
> > >>Rob
> > >>
> > >
> > >
> > > Jing
> > > Netspread Carrier
> > > http://www.netspread.com
> > >
> > >
> >
> >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail:
> > struts-user-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail:
> > struts-user-help@jakarta.apache.org
> > >>
> > >>
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > struts-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Sandeep Takhar <sa...@yahoo.com>.
I think he meant isTokenValid().
Also the form tag will create the token and you can
look at it in the source.
You can check the token higher if you want (before
population) by placing it in one of these methods on
the requestProcessor..
(not sure logistically which one has the request
signature & more importantly which one makes sense)...
This is in order:
processMultipart
processPath
processLocale
processContent
processNoCache
processPreProcess * looks promising
processMapping
processRoles
processActionForm
processPopulate
1st and 3rd are normally done in the action class.
One that handles the display and the one that you are
submitting to.
sandeep
--- Adam Hardy <ah...@cyberspaceroad.com>
wrote:
> I'm sure a quick look in the source code would give
> you what you want -
> try looking at isTokenValue() in Action.java
>
> Jing Zhou wrote:
> > ----- Original Message -----
> > From: "Rob" <bs...@insightoutsight.com.au>
> > To: <st...@jakarta.apache.org>
> > Sent: Wednesday, July 16, 2003 6:57 PM
> > Subject: dificult problem, preventing population
> (repost)
> >
> >
> >
> >>I have the following scenario occuring.
> >>
> >>I have a form with several fields on it (the
> fields are sourced to a
> >>collection in an
> >>ActionForm). I have a button that allows the
> removal of fields from the
> >>form (items
> >>from the collection). If a user removes a field
> from the form and then
> >>double
> >>submits/clicks back and reloads then an exception
> is thrown from
> >>BeanUtils.populate()
> >>because it attempts to take details from the (now
> removed field) and
> >>populate it into
> >>the object that is stored in the position it was
> located in the
> >>collection. Obviously
> >>since the collection is now smaller this results
> in an
> >>IndexOutOfBoundsException.
> >>
> >>Is there any way to examine the transaction token
> from the form prior to
> >>the form
> >>bean being populated and then avoid population of
> the form bean if the
> >>token is not
> >>valid?
> >
> >
> > There are three steps involved when using
> transaction token:
> > 1) Setting token;
> > 2) Checking token;
> > 3) Resetting token;
> >
> > It looks right if we could perform the second step
> in a subclass of
> > the RequestProcessor so that the token is checked
> before form
> > bean population. But where do we put the first
> step and the
> > third step? If we put them in an action class,
> then how does
> > the derived request processor know when it should
> check
> > the token? If we put them all in the derived
> request processor,
> > that is not correct either, because they are
> business logics not
> > applicable to every action mappings.
> >
> > The real *bad* guy is the browser's Back button
> your users
> > are using. The browser's tool bar and address bar
> are
> > intended to help load document oriented resources.
> They
> > are useless for application oriented resources in
> our
> > concepts. One good practice I saw is to turn off
> the
> > tool bar and address bar. It gives you the look
> and feel
> > of *real* applications. Of course, you must
> provide navigation
> > buttons for your applications.
> >
> > Sometimes, business people would say they *want*
> the
> > tool bar or address bar (actually they do not know
> what
> > really they want in many times :-) In such case,
> you have
> > to find a way to disable the Back button. If you
> try the
> > JavaScript location.replace() in the second page,
> it will
> > forget the past - no back any more.
> >
> > As you see, it is not easy to get a *correct*
> solution and
> > my suggestion may not be applicable to your case.
> But I
> > am interested in any further thoughts.
> >
> >
> >
> >>Help with this problem would be greatly
> appreciated.
> >>
> >>Rob
> >>
> >
> >
> > Jing
> > Netspread Carrier
> > http://www.netspread.com
> >
> >
>
>>---------------------------------------------------------------------
> >>To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
I'm sure a quick look in the source code would give you what you want -
try looking at isTokenValue() in Action.java
Jing Zhou wrote:
> ----- Original Message -----
> From: "Rob" <bs...@insightoutsight.com.au>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, July 16, 2003 6:57 PM
> Subject: dificult problem, preventing population (repost)
>
>
>
>>I have the following scenario occuring.
>>
>>I have a form with several fields on it (the fields are sourced to a
>>collection in an
>>ActionForm). I have a button that allows the removal of fields from the
>>form (items
>>from the collection). If a user removes a field from the form and then
>>double
>>submits/clicks back and reloads then an exception is thrown from
>>BeanUtils.populate()
>>because it attempts to take details from the (now removed field) and
>>populate it into
>>the object that is stored in the position it was located in the
>>collection. Obviously
>>since the collection is now smaller this results in an
>>IndexOutOfBoundsException.
>>
>>Is there any way to examine the transaction token from the form prior to
>>the form
>>bean being populated and then avoid population of the form bean if the
>>token is not
>>valid?
>
>
> There are three steps involved when using transaction token:
> 1) Setting token;
> 2) Checking token;
> 3) Resetting token;
>
> It looks right if we could perform the second step in a subclass of
> the RequestProcessor so that the token is checked before form
> bean population. But where do we put the first step and the
> third step? If we put them in an action class, then how does
> the derived request processor know when it should check
> the token? If we put them all in the derived request processor,
> that is not correct either, because they are business logics not
> applicable to every action mappings.
>
> The real *bad* guy is the browser's Back button your users
> are using. The browser's tool bar and address bar are
> intended to help load document oriented resources. They
> are useless for application oriented resources in our
> concepts. One good practice I saw is to turn off the
> tool bar and address bar. It gives you the look and feel
> of *real* applications. Of course, you must provide navigation
> buttons for your applications.
>
> Sometimes, business people would say they *want* the
> tool bar or address bar (actually they do not know what
> really they want in many times :-) In such case, you have
> to find a way to disable the Back button. If you try the
> JavaScript location.replace() in the second page, it will
> forget the past - no back any more.
>
> As you see, it is not easy to get a *correct* solution and
> my suggestion may not be applicable to your case. But I
> am interested in any further thoughts.
>
>
>
>>Help with this problem would be greatly appreciated.
>>
>>Rob
>>
>
>
> Jing
> Netspread Carrier
> http://www.netspread.com
>
>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: dificult problem, preventing population (repost)
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Rob" <bs...@insightoutsight.com.au>
To: <st...@jakarta.apache.org>
Sent: Wednesday, July 16, 2003 6:57 PM
Subject: dificult problem, preventing population (repost)
> I have the following scenario occuring.
>
> I have a form with several fields on it (the fields are sourced to a
> collection in an
> ActionForm). I have a button that allows the removal of fields from the
> form (items
> from the collection). If a user removes a field from the form and then
> double
> submits/clicks back and reloads then an exception is thrown from
> BeanUtils.populate()
> because it attempts to take details from the (now removed field) and
> populate it into
> the object that is stored in the position it was located in the
> collection. Obviously
> since the collection is now smaller this results in an
> IndexOutOfBoundsException.
>
> Is there any way to examine the transaction token from the form prior to
> the form
> bean being populated and then avoid population of the form bean if the
> token is not
> valid?
There are three steps involved when using transaction token:
1) Setting token;
2) Checking token;
3) Resetting token;
It looks right if we could perform the second step in a subclass of
the RequestProcessor so that the token is checked before form
bean population. But where do we put the first step and the
third step? If we put them in an action class, then how does
the derived request processor know when it should check
the token? If we put them all in the derived request processor,
that is not correct either, because they are business logics not
applicable to every action mappings.
The real *bad* guy is the browser's Back button your users
are using. The browser's tool bar and address bar are
intended to help load document oriented resources. They
are useless for application oriented resources in our
concepts. One good practice I saw is to turn off the
tool bar and address bar. It gives you the look and feel
of *real* applications. Of course, you must provide navigation
buttons for your applications.
Sometimes, business people would say they *want* the
tool bar or address bar (actually they do not know what
really they want in many times :-) In such case, you have
to find a way to disable the Back button. If you try the
JavaScript location.replace() in the second page, it will
forget the past - no back any more.
As you see, it is not easy to get a *correct* solution and
my suggestion may not be applicable to your case. But I
am interested in any further thoughts.
>
> Help with this problem would be greatly appreciated.
>
> Rob
>
Jing
Netspread Carrier
http://www.netspread.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org