click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <>
Subject Re: Page flows within a click application
Date Sat, 13 Nov 2010 09:02:05 GMT
I think the new PageInterceptor would be a good way of implementing a
navigation stack, as you can store the navigation stack in the session and a
PageInterceptor can be responsible for building it up.

regards Malcolm Edgar

On Sat, Nov 13, 2010 at 1:26 PM, Bob Schellink <> wrote:

> Hi St├ęphane,
> This is more of a general web flow question than Click specific. From what
> you describe it sounds as
> if you don't have a page flow in your app. You simply want to unwind their
> browser history? In other
> word there is no knowledge of where users should go next?
> In that case you'll need to use either the session or cookies to track
> history and unwind the stack
> when needed. If your requirements are to always navigate users back, I
> don't see another way really.
> In our app we generally have our main navigation through a drop-down menu
> to navigate to the various
> parts of the system. That often leads to a master page where users can
> drill into a detail page and
> back to the master.So back for us means back to the master. This is quite
> similar to how the Click
> examples work as well.
> Another pattern is to use a breadcrumb. However I've often seen breadcrumbs
> implemented as history
> bars[1][2] which doesn't add much since browsers have back buttons.
> On 13/11/2010 02:24, St├ęphane NICOLAS wrote:
> >
> > I got a question that remains unanswered after many attempts to solve it
> : page flows.
> >
> > I made a pretty app with click. It handles the editing and listing of 6
> different types of data, all
> > interlinked.
> > But I don't have a very good model to deal with the page flow inside my
> application.
> >
> > --- All I want is a button, on each page to come back to where you come
> from.---
> > (and of course I got many links inside my app to go to different pages)
> >
> > *It seems to me that if I use the "referrer" technique, with hidden
> fileds on post and url params on
> > get, I can achieve only one level of depth to remember the page where I
> come from. But I can't
> > remember the pages before that.
> >
> > *If I use the history.back (javascript) technique, it 's not possible to
> deal with the post
> > mechanism inside the application, it always
> I've found history.back quite problematic and never use it. To get around
> POST issues, use the
> Redirect after Post pattern[3]. Example here[4].
> > gonna resubmit. It prevent that with a onSecurityCheck but then a user
> would get errors just by
> > coming back to a page S/he posted.
> >
> > So, I don't see clearly a clean model to ease page navigation and that
> remains a real mystery to me.
> >
> > One solution though would be to put a kind of history in the session, but
> having done all those
> > efforts not to rely on sessions, putting hidden fields every where, it
> seems a pity.
> In the end it boils down to your requirements and what will provide the
> best experience.
> Kind regards
> Bob
> [1]:
> [2]:
> [3]:
> [4]:> Edit

View raw message