cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: Proposal for caching
Date Thu, 25 Jan 2001 14:40:16 GMT
> Berin Loritsch wrote
> > OK, now I get what you meant. I think it is really a good idea. It would
> > lead to a repository of possible, configurable validators (equivalent
> > to the repository of generators, transformers etc.) and the sitemap
> > designer chooses the right validator for the component.
> > But it is not possible to write validators which are usable for any
> > component as only the component knows which data to test. So you
> > have a tight coupling between a component and its validators.
> 
> If there is a tight coupling between validators, then we need to look at
> coupling them.  More down below.
> 
> > Quickly thinking I see a possible solution:
> > Each component declares his own usable validators which can only be used
> > with this component:
> > 
> > <map:generators>
> >     <map:generator label="content" name="file" 
> src="org.apache.cocoon.generation.FileGenerator">
> >         <map:validators>
> >            <map:validator name="fileChangedValidator" class 
> ="org.apache.cocoon.validation.FileChangedValidator"/>
> >            ....
> >         </map:validators>
> >     </map:generator>
> > <map:generators>
> > ...
> >    <map:match="test">
> >      <map:generate src="http://myserver/resource.xml"
> >           type="http"
> >            validator="fileChangedValidator">
> >      </map:generate>
> >       ...
> >    </map:match>
> > 
> > What do you think about this?
> 
> I think that modifying the sitemap like this only serves to make
> things more confusing or at least cluttered.  I understand the
> idea of swapping Validators, but I think that might be flexibility
> syndrome.  How many ways is a FileGenerator going to invalidate
> a cache entry for a File?  I do think they should be external
> components, but I also think that they should be hard-wired to
> the Component.
> 
> FileGenerator {
>    Validator validator = new FileChangedValidator();
> 
>    ......
>  
>    generate() {
>       if (validator.hasChanged(file) {
>           // normal processing
>       } else {
>           // retrieve from cache.
>       }
>    }
> }
> 
OK, perhaps a file generator is a bad example, lets take the SQLTransformer.
There might be different use cases for it:
- The content is invald every day at 6 in the morning
- The content is valid four 3 hours
- On weekdays the content is valid for 2 hours and never changes on sat./sun.
Perhaps this is FS using different validator classes. My first thoughts
were, that there is a base abstract ValidatorClass which can handle all of that
above. Each component is coupled with its own validator (like in your example 
above) and it can (not must) be configured in the sitemap:
    <map:match="test">
     <map:generate src="http://myserver/resource.xml" type="http">
		<map:parameter name="validator_valid_period" value="3 hours"/>
     </map:generate>
            or
     <map:generate src="http://myserver/resource.xml" type="http">
		<map:parameter name="validator_invalidate_at" value="6 in the morning"/>
     </map:generate>      ...
   </map:match>
But in this case it is required that each validator has some basic functions like
them above.
I like this approach more than the pool of validators as the sitemap designer
has not to care about validators. He uses only some simple parameters.
The pool-approach is more flexible and allows custom validators which can do
whatever they want.


Carsten


Mime
View raw message