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
