cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Escaping Sitemap Hell
Date Thu, 06 Jan 2005 11:37:19 GMT
Niclas Hedhman wrote:

>On Thursday 06 January 2005 08:54, Daniel Fagerstrom wrote:
>
>Good post !
>
Thanks :)

>>But you shouldn't require your user to remember
>>different URLs for different clients, thats a task for server driven
>>content negotiation.
>>
>>Using .html is not especially future proof, should all links become
>>invalid when you decide to reimplement your site with dynamic SVG?
>>    
>>
>
>I have thought about this a million times over the last 5 years, and first 
>concluded "yeah, let's do that", and then back tracked since the file system 
>is not 'negotiating' and having the same stuff working locally is always a 
>big plus.
>
Are you refering to the Forrest kind of situation where you can generate 
a static "site" at your hard disk and access it directly?

Even in such situations you could, at least in principle, do format 
negotiation by leting the "cool" file URL point to a html page that has 
alternate media type liks 
http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3, 
http://www.w3.org/TR/REC-html40/types.html#type-media-descriptors. Then 
the media type links in turn points to the screen, tty, projection, 
handheld, print etc page that the browser can use, depending on its 
preferences. The altenate media pages could in turn have a bookmark link 
that point to the cool URL. I don't know if this works well in practice 
with common browsers.

As I'm rather fed up with the URL space hell that I have created in my 
own applications, I choosed to take a fundamentalistic view concerning 
"fixed and independed semantics" of URLs to see where it leads. And as 
you could see in the second half of my post it is not only some file 
systems that have limited support for cool URLs, AFAIK Cocoons support 
is rather limited as well.

Now in practice I think that URL space design have similarities with API 
design. For some externally used intefaces and URLs, the cost of change 
is very high as many users depend on them, for internal interfaces and 
URLs the cost of change is much lower, so you don't need to care that 
much about the design. But exposing lots of internal implementation 
details in your APIs and URL spaces is often to ask for trouble.

>>But it is not a law of nature that it must be like that. It is
>>mainly a result of webapp development still being immature and 
>>the tools being far from perfect. Of course the user should be 
>>able to bookmark a useful form or wizard.
>>    
>>
>
>Now you have the interesting thing of 'temporary URLs' used for session 
>sensitivity. How often doesn't one bookmark a page and later coming back 
>"Session has expired" type of resource not found??
>Would be real cool if the web app system could help dramatically in this 
>field.
>
The W3C note i refered to has some guidelines 
http://www.w3.org/TR/2003/NOTE-chips-20030128/#gl3.

My view is that we should strive for making it as easy as possible to 
follow god web practicies (like those described in 
http://www.w3.org/TR/2003/NOTE-chips-20030128/), when using Cocoon.

>As a sidenote; Tapestry is battling with these types of problems as well (but 
>a somewhat different level), and handles it by allowing an interceptor in the 
>URL encoding/decoding phase.
>
Do you have any references that sumarize that?

> The internal URL space remains, and a 
>user-created component translates URLs back and forth between the public 
>space and the internal one.
>
That is similar to what I propose. The new tree structured sitemap 
translates public URLs to an internal space of (virtual) pipeline calls. 
Due to Cocoons dynamic nature the internal "URL space", is more abstract 
than file reference URLs, but we can (and probably should) make it an 
URL space anyway.

The XFrames URIs http://www.w3.org/TR/xframes/ can serve as inspiration:

|  http://example.org/home.frm#frames(id1=uri1,id2=uri2,...)

We can have:

  block:myblock#bar-chart-view(data=mydata.xml)

Where relative URLs ("mydata.xml" in this case) are relative to the 
current context (actually it is a little bit more complicated 
http://marc.theaimsgroup.com/?t=110064560900003&r=1&w=2). The current 
context can be set at each level in the tree sitemap.

Thanks to the declarative nature of my proposed tree sitemap and that 
the wildcards are "typed" so that their range can be found, the sitemap 
can be inverted to a maping from internal URLs to external ones.


|/Daniel



Mime
View raw message