cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Carvalho <>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Sat, 06 Oct 2001 12:55:10 GMT
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
> 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

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.

> It very well might be quicker.  I have an idea that is not tree traversal,
> but it would work equally well.  The short description is this:
> All pipelines are pre-configured and treated as proper components.  As a
> URI request comes in, it is fed to the Sitemap Pipeline Selector.  This
> approach takes advantage of pooling, and as specific pipelines are used,
> the pool keeps enough in memory.  Thus, the pipelines that are used less
> often don't have as many instances.
> In the end, the structure of a pipeline is configurable--encapsulating
> sub-sitemaps and all the other logic.  With the pipeline centric approach,
> the lookup is done via a HashMap scheme which has proven to be efficient
> during runtime.  The maximum number of lookups is directly related to
> the number of sub sitemaps.
> This proposal combined with Cocoon Apps (with the URIMap, FlowMap, and
> named Cocoon components) would be very effective.  The shift in focus
> of the URIMap vs. the Sitemap automatically gets you thinking what will
> be the least amount of work to achieve the desired URI space.  The URI
> space will be immediately known--and 404 errors can be even more quickly
> returned.
> 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.

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. 

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. 

Sergio Carvalho

If at first you don't succeed, skydiving is not for you

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

View raw message