cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <peter.hunsber...@gmail.com>
Subject Re: [RT] Escaping Sitemap Hell
Date Wed, 12 Jan 2005 18:41:59 GMT
On Wed, 12 Jan 2005 12:04:38 -0600, Glen Ezkovich <glen@hard-bop.com> wrote:

> 
> On Jan 12, 2005, at 9:17 AM, Peter Hunsberger wrote:
> 
> > On Sat, 8 Jan 2005 18:48:29 -0600, Glen Ezkovich <glen@hard-bop.com>
> > 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.

Certainly not.  However, URL's can still be a convenient, even good,
way to encode state, in particular if the state representation is
valid across multiple other concerns.

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

Sure, if you don't need any adoption/resumption of the state across
browsers then form variables work fine. However, we _do_ design our
applications for resumption upon resumed sessions.  In particular, we
do timed out session recovery/resumption after reauthentication.

<snip/>

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

Yes: but that's exactly the current situation.  The reality of the Web
is that it's a graph.  Graph theory tells us that's there's no
algorithm for generalized graph traversal that will be guaranteed to
finish in finite time for all graphs.  So, no single solution can work
for all Cocoon apps.  So far Cocoon has three ways (at least) to
attack the problem of customized graph traversal:

1) the sitemap with the default matchers;

2) pluggable matchers;

3) flow.

There seems to be very little exploration of 2), as has been kicked
around in this thread at least part of the solution may lie in some
new types of matchers.

For some reason some people seem to want to avoid 3), even with Java
flow (as opposed to flow script).  The other issue here is that 3) 
currently makes it hard to get back a URL-map so there's problems with
debugging (and arguably potential security exposures).

What I'd like is something new that would attack 2) and 3)
simultaneously: an XSLT version of the sitemap.  However, as I said,
I've argued for this before and I still don't think I can make a
convincing case that it would solve anyone's problems than my own...

<snip/>

> 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

It's not clear that a tree matcher can be implemented with the current
sitemap: either you match or you don't, there's no way of "voting" on
how well you match.  I think to get a true TreeMatcher you'd also need
to change some parts of the Cocoon internals (to evaluate what a best
match means or to track past match context). IOW, you'd need something
other than the current sitemap (even if the syntax remains backwards
compatible)...

-- 
Peter Hunsberger

Mime
View raw message