Niclas Hedhman wrote:
On Thursday 06 January 2005 08:54, Daniel Fagerstrom wrote:
Good post !
Thanks :)
Are you refering to the Forrest kind of situation where you can generate a static "site" at your hard disk and access it directly?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.
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.
The W3C note i refered to has some guidelines http://www.w3.org/TR/2003/NOTE-chips-20030128/#gl3.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.
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
