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.
http://click.apache.org/docs/click-api/org/apache/click/PageInterceptor.html regards Malcolm Edgar <http://click.apache.org/docs/click-api/org/apache/click/PageInterceptor.html> On Sat, Nov 13, 2010 at 1:26 PM, Bob Schellink <[email protected]> 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]: http://clickclick-examples.appspot.com/home.htm > [2]: > > http://code.google.com/p/clickclick/source/browse/trunk/clickclick/core/src/net/sf/clickclick/control/breadcrumb > [3]:http://click.apache.org/docs/faq.html#multiple-posts > [4]: http://click.avoka.com/click-examples/introduction/advanced-table.htm-> > Edit customer >
