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 Sun, 14 Nov 2010 01:27:37 GMT
Glad you got it working. The improvements to Breadcrumb looks very good.

Thanks

Bob

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,
not
> 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 <sabob1@gmail.com <mailto:sabob1@gmail.com>>
> 
>     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