cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <atagu...@nnt.ru>
Subject Re: AW: [C2]: Proposal for caching
Date Thu, 25 Jan 2001 13:35:43 GMT
On Thu, 25 Jan 2001 08:19:31 -0500, Berin Loritsch wrote:

>Carsten Ziegeler 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.
>      }
>   }
>}
>

Feel a little awkward to object (I'm a lurker :), but actully because of this we maybe will
have
to derive our own implementations of Components, just to change the caching policy.

Plz, see my prev e-mail with our use-case and how we changed the caching policy
for XInclude from URL-s. BTW: as for databases, I feel very much that my
components should be able to accept some kind of "INVALIDATE" singnal from outside,
called when a particular table in the DB gets changed.. I'm not sure on how to do it,
maybe, provide some CORBA interface for my Cocon component, EJB interface,
or explore CRUDLET architecture, but for me it is very desireable to have FLEXIBLE
caching policy.. BTW: even for a File we can imaging using the "hard"/"soft"+timeout
caching policy we have developed for URL's (see my prev e-mail). 

Best regards, Tagunov Anthony

P.S. Someone on the list has spoken of some "OO" way of caching and lots of 
flexibility connected with it. Sorry, can't find that e-mail, what was it?



Mime
View raw message