cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: [RT] Escaping Sitemap Hell
Date Thu, 06 Jan 2005 19:19:40 GMT

On Jan 6, 2005, at 11:12 AM, Daniel Fagerstrom wrote:

> How much work you should spend in creating "cool" URLs in your webapp, 
> varies of course from application to application. I just wanted to 
> point out that we can do more than 123456.cont if we want to. I have 
> used more than one webapp that goes through many "transactions" during 
> use, but force me to start the navigation from some start screen if my 
> session expires. At least I would found such applications more 
> userfriendly if they had used "cooler" URIs.

What do you mean by "transactions"? If the "transaction" is only 
"committed" to the Session then once the session expires there is no 
going back no matter how cool the URI. If the "transaction" is 
committed to persistent storage then continuation is possible. However, 
using flow to achieve this is dubious at best. Once such a transaction 
is completed it seems wiser to use sendPage and if more control is 
needed to pass it to a different function and create a new continuation 
hierarchy. If a user can return to a site days latter and continue 
where they left off its likely that the same URI from which they 
started will be the one they use to continue, with the business layer 
determining where they should start. The simple case would be an single 
page form that can be saved at any point. A more complex case would be 
an eLearning or testing application where each request requires the 
users place to be saved. In both cases we are talking of a single 
resource that is controlled in the business layer and not in flow. In 
such applications the use of flow is simply to mediate between the 
presentation and the model; i.e. validate input or display a reading 
selection and then present questions to be answered.

No matter how cool the URI, its the application that determines the 
user friendliness. If you're session expired you will have to log in or 
have a cookie with your data to continue where you left off. Whether 
each page has a unique URI is unimportant as long as the application is 
smart enough to know where you left off.

On a related note, the idea of using 123456.cont as part of a URI that 
a user can see is SOOO UNCOOL. Hide these things in forms so a user 
will never see them. Once a user enters a flow that should be the last 
and only URL they see in the address bar until they exit flow and/or 
choose to move to a new resource.

Holding such a view as to how and when to use flow allows cool URLs 
since the resource essentially is a flow function that controls user 
interaction with the model; in other words  a mini-application.

The point is as things currently stand cool URLs are possible even 
considering flow.

> If you think that reusable URLs is a good idea, not only in publishing 
> oriented sites but in webapps as well, you will need to have more 
> external URLs and your webapp will get more in common with publishing 
> oriented sites.

URL wise there is no reason for them to be different, at least from a 
user perspective. Further, there never was. I don't see the need to 
have more external URIs, I just better designed web applications. The 
resource is the application not an individual page the application 

To my mind what a tree based sitemap buys is a better model of the site 
as application (publication or webapp).  Because of that it just might 
lead to cooler URLs but not guarantee it.


Glen Ezkovich
HardBop Consulting
glen at

A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

View raw message