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