cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Deprecation of CInclude transformer
Date Wed, 21 Nov 2007 13:11:38 GMT
Ard Schrijvers wrote:
<snip/>
> Now, the IncludeTransformer adds the validity object of the included
> sources to the validity object of the calling pipeline (pfffffff....).
> Let's have an example:
> 
> someXML.xml : 
> 
> <doc>
> 	<include:include src="cocoon://fetchSnippet"/>
> </doc>
> 
> <map:match pattern="main">
> 	<map:generate src="someXML.xml"/>
> 	<map:transform type="include"/>
> 	<map:serialize/>
> </map:match
> 
> <map:match pattern="fetchSnippet">
> 	<map:generate src="included.xml"/>
> 	<map:serialize/>
> </map:match>
> 
> included.xml : <includethis/>
> 
> So, when calling /main, I will get 
> 
> <doc>
> 	<includethis>	
> </doc>
> 
> and the validity object of the "fetchSnippet" pipeline is added to the
> validity of the "main" pipeline. So, the second call for /main, does the
> setup for the "main" pipeline, and computes a cachekey....and finds a
> hit in the cache with a valid cached object, thus returns the cached
> result. NOTE: the second pipeline is never used in the second call. Not
> even the setup!
> 
> Suppose I change now the second matcher the src from included.xml to
> included2.xml, and call /main again....Well, my cachekey of the first
> pipeline is unchanged, as well as the validity object (the validity
> object is with respect to included.xml which did *not* change). So, I
> still get the same cached result. Now, when I open "included.xml",
> change something and save, then the validity obj of the first pipe is
> invalid, so the result is re-computed, fetching included2.xml!! 

Indeed. I think this is a failure on CocoonSource part. CocoonSource content 
depends on the sitemap.xmap, but CocoonSource validity does not include validity 
of the sitemap. As a result, even if sitemap is changed, CocoonSource validity 
stays valid.

I'm not sure though if I want to have this bug fixed - it would add more overhead...


> Also, if the second pipeline /fetchSnippet start with a map:select
> first, the things are getting even complexer (the little catch)....if
> somebody wants to know about it I can elaborate.

Fire away! ;-)


> Anyway, why use the IncludeTransformer if you have this 'strange'
> behavior....Well, it is just way much faster than the
> CIncludeTransformer, so if you have pipelines with 10-20 includes (which
> we have in some projects) I want a cached result withing a couplt of ms.
> Do realize, that setting up a pipeline, compute the compound cachekey of
> a generators and transformers, check the cache, check the validity
> object, do take time, which you do not have with the includetransformer
> (it only returns the validity obj). OTOH, it really only makes sense to
> use it when you have a lot of traffic, or when pages have to load fast. 

BTW IncludeTransformer operation can not be changed easily. If you try to 
resolve each included URI, to check its new key and validity, you'd also have to 
parse (or store somewhere!) included parts in order to resolve nested includes - 
if recursive inclusion is switched on.


> Hope things are a little clear. Sorry I cannot say to much about the
> CIncludeTransformer...I just do not know enough about it. I just know it
> is much slower (I just looked at the code and see it uses a
> cachingSession with an expires...i do not like it that much i think,
> though it can be used for much more than the IncludeTransformer)

IMHO POSTing stuff to a source does not really belong to a include transformer, 
but rather to some other type of transformer...

Vadim


> Regards Ard
> 
>> BTW. I forgot to say that I would like to deprecate CInclude 
>> in 2.2 only.
>>
>> --
>> Grzegorz Kossakowski


Mime
View raw message