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 <[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]
