cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Deprecation of CInclude transformer
Date Fri, 23 Nov 2007 01:21:52 GMT
Ard Schrijvers wrote:
>> Vadim Gritsenko wrote:
>> 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...
> Don't think either it is worth the trouble. You can work years with it
> without ever noticing, it is only happening during development when you
> happen to change something in a way described above (which will hardly
> ever happen)

Nod. Agree.

>>> 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! ;-)
> Okay, you asked for it :-) 
> Suppose I have an include : 
> <include:include src="cocoon://fetchSnippet"/> 
> and I have a pipeline :
> <map:selectors default="parameter">
>       <map:selector name="simple"
> src="org.apache.cocoon.selection.SimpleSelector"/>
>     </map:selectors>
> <map:match pattern="fetchSnippet">
> 	<map:select type="simple">
> 		<map:parameter name="value"
> value="{request-param:strange}"/>
> 		<map:when test="true">
> 			<map:generate src="test1.xml"/>
> 		</map:when>
> 		<map:otherwise>
> 			<map:generate src="test2.xml"/>
> 		</map:otherwise>
> 	</map:select>	
>       <map:serialize type="xml"/> 
> </map:match>
> Now, when your first call is for example : /main?strange=true
> and the main pipeline is again 
> <map:match pattern="main">
> 	<map:generate src="someXML.xml"/>
> 	<map:transform type="include"/>
> 	<map:serialize/>
> </map:match>
> You will have included test1.xml, since {request-param:strange}
> evaluates to 'true'. Now, calling  
> /main?strange=false will *not* give you test2.xml as the include,
> because, the main pipeline was perfectly cacheable, the 'stange'
> parameter was not included in its cachekey and the validity object is
> valid since no src whatsoever changed. Touching again test1.xml and
> calling again returns you test2.xml. Calling /main?strange=true
> afterwards gives you again test2.xml.


Have you seen this part?

      * <p>Return the caching key associated with this transformation.</p>
      * <p>When including <code>cocoon://</code> sources with dynamic
      * content depending on environment (request parameters, session attributes,
      * etc), it makes sense to provide such environment values to the transformer
      * to be included into the key using <code>key</code> sitemap parameter.</p>
      * @see CacheableProcessingComponent#getKey()
     public Serializable getKey() {
          * In case of including "cocoon://" or other dynamic sources key
          * ideally has to include ProcessingPipelineKey of the included
          * "cocoon://" sources, but it's not possible as at this time
          * we don't know yet which sources will get included into the
          * response.
          * Hence, javadoc recommends providing key using sitemap parameter.
         return key == null? "I": "I" + key;

> You might consider it undesirable/incorrect behavior, but I just learned
> to use see the include transformer as if you add some pipeline parts
> from another pipe in your pipeline. So, if you have an include involving
> a map:select, you might see as if you were adding the pipe parts which
> are resolved by the map:select. 

All you need to do is to pass in extra key:

  <map:match pattern="main">
    <map:generate src="someXML.xml"/>
    <map:transform type="include">
      <map:parameter name="key" value="{request-param:strange}"/>

> Also, the times I had to deal with this are few, but, OTOH, when I got
> the pleasure of debugging externally developed websites with a main
> sitemap of > 4.000 lines, and this was actually one of the problems, you
> can imagine how hard it is to find! :-) 
>> 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.
> Yes indeed. We certainly do not want that! It is working really fine
> ATM, but if you encounter one of the exceptional examples I
> described....well, then you either have to learn about cocoon caching,
> or put you pipelines to noncaching :-) 

Hopefully information above helps you to keep them caching :)

>> IMHO POSTing stuff to a source does not really belong to a 
>> include transformer, but rather to some other type of transformer...
> A PostTransformer :-) 

Personally I'd not limit it to specific HTTP method, but allow to specify any 
HTTP method, headers, and request body you want. HTTPRequestTransformer?


View raw message