You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2003/07/26 18:12:07 UTC
processing flow for (was: )
(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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: processing flow for (was: )
Posted by Marc Portier <mp...@outerthought.org>.
I just remembered (and easily found the link at the bottom of
http://wiki.cocoondev.org/Wiki.jsp?page=ResourceNaming)
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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: processing flow for
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Joerg Heinicke wrote:
>
<snip />
> So we can consider resources as "gosub" and no more "goto" as stated in
> the doc. Moreover, since resources can be passed parameters, they are
> actually functions ! I can't remember if a formal vote occured on this,
> but people globally found this feature usefull.
^^^^^^^^^^
the man is so honest, there was actually a sigh of relieve
throughout the entire galaxy :-)
much of the viewed side-effects to be observed here:
http://hubblesite.org/newscenter/archive/
>
> Time to update the docs...
>
I'm prepping up a rewrite of some the wiki pages as a doco patch
(unless someone beats me to it)
> Sylvain
>
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: processing flow for
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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?
Yes : the culprit is me ;-)
The compiled sitemap engine enforced the "doesn't return" feature. When
writing the interpreted engine (the only one available in 2.1), I
introduced a "bug" which was causing resources to return if the
processing wasn't terminated. As resources were meant to close the
pipeline, this made no difference... until the day where someone forgot
to close it and discovered we could return from resources.
So we can consider resources as "gosub" and no more "goto" as stated in
the doc. Moreover, since resources can be passed parameters, they are
actually functions ! I can't remember if a formal vote occured on this,
but people globally found this feature usefull.
Time to update the docs...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: processing flow for (was: )
Posted by Marc Portier <mp...@outerthought.org>.
I just remembered (and easily found the link at the bottom of
http://wiki.cocoondev.org/Wiki.jsp?page=ResourceNaming)
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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org