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 Wed, 12 Jan 2005 18:04:38 GMT

On Jan 12, 2005, at 9:17 AM, Peter Hunsberger wrote:

> 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.

Easiest, not necessarily the best. As always it depends on your 
resources and use cases as to which solution is best. An application 
designed to handle authorizations, time outs and/or resumed sessions 
probably should not depend on URLs to accomplish these tasks.

At a single session level I think you can keep this information private 
by using forms. Users will not see the query that contains the data you 
are tracking. Sure the user can't come back after closing their browser 
and pick up where they left off, but you really didn't design your 
application for this.

> I've done
> some strange hacks to work around this in my life, but a structured
> URL can definitely make life easier.

Always. I don't think anyone will argue against this. :-))

>>>> 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 think his argument is stronger then that. If you implement a sitemap 
structure that maps perfectly to 80% of the use cases, there is a good 
chance that the other 20% would be impossible to achieve using that 
structure or at the very least require considerable hacking.

> 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...

Matching is deferent then restructuring the sitemap. I don't believe 
Stefano would have a problem with a TreeMatcher. But I could be wrong. 

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