click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <sab...@gmail.com>
Subject Re: Page flows within a click application
Date Sat, 13 Nov 2010 02:26:18 GMT
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

Mime
View raw message