click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <>
Subject Re: Page flows within a click application
Date Sun, 14 Nov 2010 01:27:37 GMT
Glad you got it working. The improvements to Breadcrumb looks very good.



On 14/11/2010 01:03, Stéphane NICOLAS wrote:
> Hi all,
> thank you bob for your answer. I understand my problem was more of a general design concern
than a
> real click centric problem.
> As I needed to go be able to track the whole history of navigation of my users, I used
the bread
> crumb implementation from click click.
> Nevertheless, the breadcrumb was not enough for me as I wanted to be able to record parameters,
> only paths of pages, into the bread crumb. Thus I modified the breadcrumb to provide
2 additional
> propreties :  currentpageurl and currentpagename.
> Both can be set at init time and are optional. The first one allows to customize the
url that is
> added to the breadcrumb when recording the current page (and thus adding parameters)
and the second
> one allows to custmize the label of the current page in the breadcrumb.
> People can also get access to the last visited page url through the
> getCurrentReferrer. This is handy if you want a button/link "return to previous page"
inside your page.
> Here attached, you will find a patch for those classes.
> (sorry package names are not valid)
> Thanks for your help, my click app rocks. :)
> Stéphane
> 2010/11/12 Bob Schellink < <>>
>     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
>     >
>     > 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 customer

View raw message