cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Caching in cocoon, especially CIncludeTransformer
Date Mon, 02 Jun 2003 12:21:47 GMT
Torsten Knodt wrote:

>On Sunday 01 June 2003 15:47, Carsten Ziegeler wrote:
>CZ> There is already such a component, the cinclude transformer uses this
>CZ> for the caching. It should be easy to use that component in the
>CZ> xinclude transformer as well.

Please, add a blank line before the reply, this will make reading easier.

>Yes, I know. But it'S still to much coding for it in the CIncludeTransformer. Components
which need the content of a source, should simply get it, and not think about caching. It's
not their job. Caching is needed in to many places. All places which use sources, should have
caching. It should only be done at one place for each kind of data.

As Carsten, I don't agree with this : caching must be optional, and is 
not useful in every place.

Take for example the XSLTProcessor : caching the source content from 
which the stylesheet was read is useless, since we keep in the store the 
corresponding pre-analyzed Templates object. The _validity_ of the 
source is important to know if the stylesheet has changed, but caching 
the stylesheet as DOM or SAX events is just waste of memory.

Another example are the "cocoon:" sources for which caching the source 
is _always_ useless :
- either the called pipeline is cacheable in which case its contents is 
stored in the Cocoon cache,
- either the called pipeline is not cacheable, and then caching the 
source result is also useless, since this content will always be invalid.

>So what I suggest is introducing SourceUtil.getInputStream for InputStream's of sources.
Then modify toDOM and toSAX to cache their output, to not have them to parse them first out
of the cached InputStream's. So we would cache InputStream's, DOM's and SAX streams. The only
changes in the components would be to use SourceUtil, where they currently use their own code.

I don't like all those static methods that hardcode more and more logic, 
and even less when they lookup some components...

Why aren't these methods part of a CocoonResolver component that would 
extend Excalibur's SourceResolver with some XML-related features ?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message