that there already was some stuff said about this...
somewhere on the side of the FOM discussion: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105407766715121&w=2
proposal being (as it is somewhat hidden in that thread) to have 'composed' sitemap components like this:
Stefano wrote (in link mentioned above):
Look at the difference between:
<map:resource name="xhtml"> <map:transformer type="link-translation"/> <map:serializer type="xhtml"/> <map:resource>
<map:match pattern="..."> <map:generate src="..."/> <map:transform src="..."/> <map:call resource="xhtml"/> </map:match>
compared with
<map:serializer name="xhtml"> <map:transformer type="link-translation"/> <map:serializer type="xhtml"/> <map:serializer>
<map:match pattern="..."> <map:generate src="..."/> <map:transform src="..."/> <map:serialize type="xhtml"/> </map:match>
which more nicely tackles the issue covered in the ResourceNaming wiki page
I don't remember any resolution/vote... I do remember a spin-off thread (aha, there it is) http://marc.theaimsgroup.com/?t=105410105900001&r=1&w=2
with subject 'Overloaded pipeline elements' (what should of have been 'Composed pipeline elements' IMHO
sorry if this adds onto the confusion, but it could help memory...
regards,
-marc=
PS: to make it even worse: by coincidence the generalized flow discussion also brings us to reconsidering the map:call for the flow stuff, might be sensible to do the changes in one sweap?
Joerg Heinicke wrote:
(Moving this discussion to dev list because it implies an more or less important change - wanted or not.)
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=
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
