cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craeg Strong <>
Subject Re: Pattern for use of sub-pipelines to grab content at different stages?
Date Wed, 24 May 2006 16:33:48 GMT

Peter Hunsberger wrote:
> What you want is user specific data components, not user specific
> presentation components.  The presentation is the last thing to go out
> the pipeline (the final set of assembled data components).    Don't
> think in terms of HTML, think in terms of XML that can easily be
> converted into HTML.  The HTML presentation details are in the final
> XSLT.  The XML data components are what are aggregated (and cached).

Yes.  For us Toplink caches business objects (avoiding trips to database),
the presentation tier caches certain long-lived DTOs (avoiding trips to 
and also caches many of the Doms of XML that are produced (avoiding 
Java-to-XML generation via JDOM).

However that still is not enough-- the XSLT processing itself--the 
transformers that produce the
final content from generated XML--are taking too long.  We want to cache 
as much of that as we possibly
can.  After all, XHTML is just XML, why shouldn't some of it be cached??
> That's not to say the final result can't be cached.  It can, but it's
> cache validity is only as good as the cache validity of that of the
> shortest lived data component. 
I don't understand.
I thought that each pipeline can be cached.

My mental model is as follows:
Say Pipeline A gets content from Pipeline A1 and A2.
Pretend that three pipelines have several generators, transformers, and 
serializers, all of which are theoretically cacheable.
Say A1 is cached for 1 second.
Say A2 is cached for 1 year.

Pipeline A will regenerate its content, and ask A1 and A2 for their content.
A1 will regenerate its content.
A2 will serve up its *cached* content.  Why would A2 have to regenerate 
itself?  It doesn't make sense...

Urg.  My mental model must be flawed, unless "data component" does not 
include "result of pipeline"  :-{


View raw message