cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <>
Subject RE: Deprecation of CInclude transformer
Date Wed, 21 Nov 2007 13:47:08 GMT

> 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)

> > 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"

<map:match pattern="fetchSnippet">
	<map:select type="simple">
		<map:parameter name="value"
		<map:when test="true">
			<map:generate src="test1.xml"/>
			<map:generate src="test2.xml"/>
      <map:serialize type="xml"/> 

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"/>

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.

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. 

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 :-) 

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

A PostTransformer :-) 


> Vadim

View raw message