On Jan 12, 2005, at 9:17 AM, Peter Hunsberger wrote:
On Sat, 8 Jan 2005 18:48:29 -0600, Glen Ezkovich <[EMAIL PROTECTED]> 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. :-0
Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com
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
