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" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Jing Zhou" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > ----- Original Message ----- > > From: "Sandeep Takhar" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" > > <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> > > > 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" <[EMAIL PROTECTED]> > > > > > To: <[EMAIL PROTECTED]> > > > > > 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: > > > > [EMAIL PROTECTED] > > > > >>For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > SBC Yahoo! DSL - Now only $29.95 per month! > > > http://sbc.yahoo.com > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
