cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Sun, 07 Oct 2001 21:38:40 GMT
Sergio Carvalho wrote:
> 
> On Fri, 05 Oct 2001 09:52:45 -0400, Berin Loritsch wrote:
> From: Berin Loritsch <bloritsch@apache.org>
> --
> 
> >
> > 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: useit.com), 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.

I have implemented a general component for pagination and for path
expansion as part of my image gallery effort that I'll donate as soon as
it's finished (should be real soon now).
 
> > 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 think we all agree on 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.

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

I definately agree on making cocoon web application more componentizable
but I  thing it's going to be hard to get that granular.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message