struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandeep Takhar <sandeep_tak...@yahoo.com>
Subject Re: dificult problem, preventing population (repost)
Date Thu, 17 Jul 2003 17:35:13 GMT
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 <jing@netspread.com> wrote:
> 
> ----- Original Message ----- 
> From: "Sandeep Takhar" <sandeep_takhar@yahoo.com>
> To: "Struts Users Mailing List"
> <struts-user@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 <ahardy.struts@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" <bss@insightoutsight.com.au>
> > > > To: <struts-user@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


Mime
View raw message