On 2/15/06, Lixin Chu <[EMAIL PROTECTED]> wrote:
> ok, I let page A or B pass a returnURL to page C who keeps it in the session
> scoped actionForm.
I think what's being suggested is storing a reference to the "referer"
in the session, and thus circumventing any potential issues with the
Referer header being removed in some mystorious way. Not scoping an
action form to session to achieve this..
My understanding of the suggestion is like replicating the history
object in client side javascript. Which does sound like a good
suggestion.
Another suggestion could be to pass the returnUrl as a parameter
<input type="text" name="returnUrl" value="[EL or scriptlet to
getRequestURI()]" />
String returnUrl = request.getParameter("retrunUrl");
returnUrl = returnUrl.replaceFirst(request.getContextPath(),"");
return new ActionForward(returnUrl,true);
Mark
>
> On 2/15/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> >
> > Michael Jouravlev wrote:
> > > On 2/14/06, Rick Reumann <[EMAIL PROTECTED]> wrote:
> > >
> > >> In the action just look for some param like "fromPage" and key off of
> > >> that for your return. (Of course a drawback is you'll need to remember
> > >> to set this var on the pages that need it - of course there are ways
> > you
> > >> could simplify that even, if really necessary).
> > >>
> > >
> > > Using session is much simpler ;-)
> > >
> > >
> > This is one of those times I would agree :)
> >
> > My suggestion would be to have a base Action in which you set a session
> > attribute to tell which page was server. Actually, you would store two,
> > the current and the previous.
> >
> > Here's my concern... let's say you have page A and page B, from which
> > you can go to page C. From page C you want to return to page A or B as
> > appropriate. You could do this a number of ways, but what if you are
> > using the common paradigm of a setup Action for a screen, and then a
> > collection of Actions which really can be though of as event handlers
> > for a given screen (could be a DispatchAction just as well, that
> > wouldn't change anything).
> >
> > If you want to go back to page A from page C, and you got to page C by
> > maybe submitting a form, then the problem is that you got to page C via
> > an event handler in essence. But, when you return to page A, you really
> > want the setup Action to fire again. So, just recording the last
> > request isn't sufficient.
> >
> > If you have a base Action that sets that session attribute, then you can
> > have only your setup Actions extend that base class. Then, when you
> > want to return to the last page from any other page, you look up that
> > value and you now know which SETUP Action you need to call. More
> > precisely, you would look at the second value in session (think of it as
> > a stack) because every time a setup Action is called you really need to
> > push a value on the stack so that the second value on the stack is truly
> > the last page, not the current pages' setup Action.
> >
> > Does that make any sense to anyone but me?? :)
> >
> > Frank
> > > ---------------------------------------------------------------------
> > > 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]
