cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <>
Subject Re: AW: [C2]: Proposal for caching
Date Thu, 25 Jan 2001 15:11:25 GMT

On Thursday, January 25, 2001, at 02:24 PM, Sergio Carvalho wrote:

> On Thu, 25 Jan 2001 08:19:31 -0500 
> Berin Loritsch <> wrote: 
> <snip/> 
> > FileGenerator { 
> >    Validator validator = new FileChangedValidator(); 
> >  
> >    ...... 
> >   
> >    generate() { 
> >       if (validator.hasChanged(file) { 
> >           // normal processing 
> >       } else { 
> >           // retrieve from cache. 
> >       } 
> >    } 
> > } 
> No, I don't like this. Imagining that every component must have this generate() code
> cache handling in there seems awkward. A component just has to be able to tell if it's

> dirty. If it is not, then Cocoon handles cache retrieving. 

Yes, I agree here.  I don't think components (generators and transformers) should have to
handle their own caching in any way. (They shouldn't have to cache themselves, and they shouldn't
have to understand the caches to operate).  But I am also inclined to think that components
should (as Berin suggested) handle their own validators.  Can't we add a validator method
as a standard part of a component API.  The caching mechanism can check the validator and
either ask the component to regenerate its output, or feed in a cached result into the stream
(bypassing the component).

> And yes, Validator substitution is important. It does not clutter the sitemap as most
> the times the default Validator is used. When you do need a different Validator, it's

> definitely better to be able to change it on the sitemap instead of subclassing the 
> Generator just to replace the Validator.  

Sergio - any chance of expanding on this a little.  Off the top of my head I can't think of
any situation where a standard component would require more than a single validator.  I'm
not disputing that there are cases, but it might be good to be able to think about specific
cases and see whether we should be generalising our solution to cope with them, or providing
mechanisms for these cases to overide the norm.


Stuart Roebuck                        
Lead Developer                               Java, XML, MacOS X, XP, etc.
View raw message