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 Fri, 18 Jul 2003 17:37:27 GMT
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 <jing@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" <sandeep_takhar@yahoo.com>
> To: "Struts Users Mailing List"
> <struts-user@jakarta.apache.org>; "Jing
> Zhou" <jing@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 <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
> >
> >
> 
> 
>
---------------------------------------------------------------------
> 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