cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Mon, 08 Oct 2001 15:48:49 GMT
Sergio Carvalho wrote:
> On Fri, 05 Oct 2001 09:52:45 -0400, Berin Loritsch wrote:
> From: Berin Loritsch <>
> --
> >
> > Home > Projects > Cocoon > Installation
> >
> > I have been trying to come up with a good way for Cocoon to automatically
> create
> > this, and haven't come up with anything elegant.  Tree traversal would be a
> > perfect match.
> Since this is a major site usability feature (see:, it should be
> provided by core cocoon. Note that this should exist in most sites, not just
> directories.
> I currently do it with a SectionCutter action, which divides my site into
> separate hierarchic sections, and then XSLT transform those to produce both the
> advertisement html snippet, and the navigation bar. I'd be happy to donate the
> SectionCutter, although you're probably looking for something more elaborate.

Actually, this might be enough.   If you could commit the SectionCutter action,
it would help developing sites to use it.  I know it will help with navigating
the docs in Avalon and Cocoon.

> > As it is currently implemented, the Sitemap gets the implementor thinking
> > linearly instead of spacially.  In other words the view of the Sitemap
> > administrator is a straight line of if/then/else statements as opposed
> > to a two dimensional map of URI space and resources.
> Very very cool. From my experience, 20% of the pipelines perform 80% of the
> requests, so complete pipeline pooling can definitely introduce performance
> enhancements. I also vouch for avoiding code generation where possible. It's a
> real pain to debug.

Amen to that!

> I must confess I managed to miss the RTs where FlowMaps and URIMaps were
> discussed. I'm glad to see the refactoring of the sitemap concept under
> discussion. I'd like to see the sitemap be just a URI to visual component
> mapper. That would mean having the sitemap just define the aggregations which
> compose each page. It would be great from a content management perspective.

Exactly.  The FlowMap and URIMap approaches merely simplified the Sitemap
into different concern areas.  For instance, the FlowMap is vital for form
validation and application specific logic.  The URIMap is more an administrator's
concern who decides where to mount different flows or other visual resources.

> The visual components would have to be defined elsewhere, and preferrably,
> should be drop-in deployable (e.g.: jar copying). This is because most site
> components (menus, news articles, navbars, banners) could be off-the-shelf
> components, and only some data-processing pages need to be custom made.

Exactly.  That's what the other thread is attempting to address.

To unsubscribe, e-mail:
For additional commands, email:

View raw message