Heinz,

Well, as I understand it, the java.util.Stack is built using a Vector, which
I believe actually uses an Array, so performance considerations aside, the
stack size should only be limited by the heap.  So I ingore that issue...;-)
I'm not sure if you can intercept the browser navigaton button events with
JavaScript (I suspect you can in later versions), but they could then
instead trigger the loading of the "back" action in the controlling servlet,
which would send the previous page.  That will probably restrict the browser
versions you can target.

For my implementations, I supply on-page navigation controls (forward ,
back, cancel buttons/links) and discourage the user from using the browser
buttons by displaying the application pages with no browser "chrome"
(controls).  User's seem fairly comfortable with this, although some of  the
"smarties" know you can right-click on the page and get access to the Back
navigation and insist on using it....

Regards
Drew


----- Original Message -----
From: Heinz Wehner <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 31, 2000 4:26 AM
Subject: Tracking visited pages


> Drew,
>
> using a stack and anchoring it in the session object sounds like a very
> natural approach to the tracking aspect. Some decisions have to be made
> regarding the maximum stack size and what should happen in case of a
> stack overflow.
>
> Now how to trigger the "back" action? Using a "back" button in the
> generated page seems to do this without having to resort to JavaScript.
> What about the browser's "back" button? One idea is to map the behaviour
> of this button to that of the "back" button of the generated page. This
> seems to require the use of JavaScript. What do you think?
>
> Regards,
>
> Heinz Wehner
> (Karlsruhe, Germany)
>
>
> > -----Original Message-----
> >
> > I'm not sure I exactly understand your requirement Heinz, but a couple
of
> > times now I have used the java.util.Stack class to stored a LIFO queue
of
> > visited pages.  This is maintained in the application's controlling
> > servlet and stored at the session scope.  The controlling servlet
> > understands a special web action "back", which forwards to the previous
> > page by poping it off the Stack.
> >
> > I have used this mechanism to control "wizard" style interactions, where
> > the user is presented with a dynamic sequence of pages that they can
> > traverse back and forward through to eventually complete some sort of
> > system transaction.  Seems to work ok, with a bit more work I think it
> > could be abstracted out into a generic "wizard controller" class.
> >
> > Regard
> >
> > Drew Cox
> >
> >
> > > -----Original Message-----
> > >
> > > A common task to solve is navigating a hierarchy. Now how
> > > should this be implemented if every page is dynamically
> > > generated by a servlet?
> > >
> > > If the client's browser cache and JavaScript capabilities
> > > should not be used, we need some mechanism to remember the
> > > visited pages on the server. This may be done by using URL
> > > rewriting to enumerate already visited pages. The session
> > > object seems to be the right container.
> > >
> > > Is this a feasable approach? Are there other solutions?
> > >
> > > Heinz Wehner
> > > (Karlsruhe, Germany)
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to