cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [RT] Escaping Sitemap Hell
Date Wed, 12 Jan 2005 15:17:07 GMT
On Sat, 8 Jan 2005 18:48:29 -0600, Glen Ezkovich <> wrote:

<snip>stuff everyone seems to agree on</snip>\

> > You've got to allow for variations on
> > authorizations, error handling, timeouts, resumed sessions, etc.
> These do not have to be public URLs. All of these things are internal
> to the application. If you are providing your users with URLs for these
> things you should ask yourself if there is a better way to handle this.

The problem is that apps often need to track some kind of state.  Any
one of the above can affect state.  In some cases you can't rely on
session (or cookies) and URL becomes the easiest fall back.  I've done
some strange hacks to work around this in my life, but a structured
URL can definitely make life easier.

> >> As far as dogmatism and URL structure goes, you can always be dogmatic
> >> in the way you structure them. ;-)  The problem with dogmatism is that
> >> it does not always lead to the best solution for a given case. Then
> >> again sometimes it does.
> >
> > And that's this issue Daniel's worried about: what's the best
> > solution.  (However, I'm not completely sure for what problem space.)
> As always, it depends on the problem space. ;-) There is not one best
> way and thats why implementing the sitemap according to the "best way"
> to design your URL space is probably a bad idea. I do find the idea of
> a tree structured sitemap appealing (even though it works nicely with
> my "best way" :-O).

I think there are some overall patterns that can be useful for
probably 80% of the use cases. Stefano seems to believe it's not worth
trying to build anything directly into Cocoon to handle these.  I'm
not sure I can codify any rational  proposal well enough to dispel
this belief so I'll probably drop this for now.

Tree structured URL matching makes sense to me and doing it using XSLT
makes even more sense.  An XSLT flow handler is something I've been
pushing for for years now, but for the moment Javascript flow and
resolving URLs through our internal rules based matcher works fine so
I can't really justify spending any time on this...

Peter Hunsberger

View raw message