The problem: Does the processing return to a calling pipeline after <map:call resource=""/>?
The docu at http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Calling+resources and http://wiki.cocoondev.org/Wiki.jsp?page=Resources says no (to whatever reasons). But I saw Marc's example at http://wiki.cocoondev.org/Wiki.jsp?page=CleanerSiteMapsThroughResources and he tested it again and it worked, i.e. the processing flow *does* return to the calling pipeline.
Is this change implied? What were the pros and contras of this behaviour? I only know the old behaviour and, yes, the return makes the sitemap pipeline snippets more flexible. And who updates the docu ;-)
Can anybody say something about it?
Joerg
Marc Portier wrote:
Hmm, much of the code on this page is wrong or at least misleading:
<map:resource name="generate-data-xml">
<map:generate type="myCSVGenerator" src="http://csv-server.domain/getData"/>
</map:resource>
<map:resource name="generate-data-svg">
<map:call resource="generate-data-xml"/>
<map:transform src="xsl/datafilter.xsl"/>
<map:transform src="xsl/data2svg.xsl"/>
</map:resource>
A <map:call resource=""/> is a one way ticket. The processing does not return to the calling pipeline. Or do I miss anything?
I think it does... (at least it did at the time of writing since I tested the code out)
resources are pieces of pipelines that take up roles see also the accompanied page at http://wiki.cocoondev.org/Wiki.jsp?page=ResourceNaming
If that's true it must be more a bug than a feature I guess:
It is true.
Just did a simple test (using cvs head) by wrapping a generator inside a resource and replacing the <map:generate by the fresh map:call/@resource in a particular pipe (followed by transformers and serializer of course)
as for the documentation:
http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Calling+resources.
I've spent some time to figure out if the wording 'calls to a resource never return' could be interpreted in any other way but I'ld have to concede that the doco is not in sync with code reality here...
Maybe the docos are still reflecting how the previous sitemap implementation was handling things? Anyone out there aware of the history of things? (I never tested this with anything else then the treeprocessor)
In any case I think this behavior is generaly useful (as the wiki page tries to argument) and not harmful in any way...
regards, -marc=
