You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ramsés Morales <ra...@computer.org> on 2003/07/26 01:31:21 UTC
Hi.
I would like to do sitemap substitution to the type attribute of the
serializer from the wildcard matcher. I get this error:
Type '{1}' is not defined for 'serialize'
That means I can't select dynamically the serializer with this syntax?:
<map:serialize type="{1}"/>
I solved the problem using a selector, but I would really like to do it
with {1}. Is it possible?
Thanks for your help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re:
Posted by Ramsés Morales <ra...@computer.org>.
Excelent!!
That's exactly what I needed. Why didn't I think of that? :-)
Thanks.
On Sat, 2003-07-26 at 02:32, Marc Portier wrote:
> I think Resources might do it as well,
> matter off taste what you'll prefer probably...
>
> <map:resource name="serialize-typeX">
> <serialize type="typeX"/>
> </map:resource>
>
> # and more for each type...
>
>
> and then have <map:call resource="serialize-{1}" /> in your pipe
>
>
> see for more at
> http://wiki.cocoondev.org/Wiki.jsp?page=CleanerSiteMapsThroughResources
>
> -marc=
>
>
> Joerg Heinicke wrote:
> > In short: no. Selector is the right way to go.
> >
> > Joerg
> >
> > Ramsés Morales wrote:
> >
> >> Hi.
> >>
> >> I would like to do sitemap substitution to the type attribute of the
> >> serializer from the wildcard matcher. I get this error:
> >>
> >> Type '{1}' is not defined for 'serialize'
> >>
> >> That means I can't select dynamically the serializer with this syntax?:
> >>
> >> <map:serialize type="{1}"/>
> >>
> >> I solved the problem using a selector, but I would really like to do it
> >> with {1}. Is it possible?
> >>
> >> Thanks for your help.
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
pb with sql transform or HSQLDB
Posted by Bruno Pierre <br...@yahoo.fr>.
Hello everybody.
WHen i do the query
SELECT ID AS TOTO FROM ....
I get the tag <id> and not the tag <toto>
is it a problem of HSQLDB or a problem of the transformer?
To have the wanted output i'm forced to do
SELECT ID+0 AS TOTO FROM...
but it is boring
thanks
---------------------------------------------------------------------
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 (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
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
processing flow for (was: )
Posted by Joerg Heinicke <jo...@gmx.de>.
(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
processing flow for (was: )
Posted by Joerg Heinicke <jo...@gmx.de>.
(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=
Re:
Posted by Vadim Gritsenko <va...@verizon.net>.
Marc Portier wrote:
>> 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)
Bit of history:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102572946412590&w=2
In short, current sitemap behavior is due to a bug, which is now
considered an "undocumented feature". There were some other emails about
it but I can't find them.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re:
Posted by Marc Portier <mp...@outerthought.org>.
Joerg Heinicke wrote:
> 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=
>
> Joerg
>
>
> ---------------------------------------------------------------------
> 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:
Posted by Joerg Heinicke <jo...@gmx.de>.
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:
http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Calling+resources.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re:
Posted by Marc Portier <mp...@outerthought.org>.
Joerg Heinicke wrote:
> Marc Portier wrote:
>
>> I think Resources might do it as well,
>> matter off taste what you'll prefer probably...
>>
>> <map:resource name="serialize-typeX">
>> <serialize type="typeX"/>
>> </map:resource>
>>
>> # and more for each type...
>>
>>
>> and then have <map:call resource="serialize-{1}" /> in your pipe
>
>
> Ah, nice idea I didn't think of.
>
>> see for more at
>> http://wiki.cocoondev.org/Wiki.jsp?page=CleanerSiteMapsThroughResources
>
>
> 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
regards,
-marc=
> Joerg
>
>> -marc=
>>
>>
>> Joerg Heinicke wrote:
>>
>>> In short: no. Selector is the right way to go.
>>>
>>> Joerg
>>>
>>> Ramsés Morales wrote:
>>>
>>>> Hi.
>>>>
>>>> I would like to do sitemap substitution to the type attribute of the
>>>> serializer from the wildcard matcher. I get this error:
>>>>
>>>> Type '{1}' is not defined for 'serialize'
>>>>
>>>> That means I can't select dynamically the serializer with this syntax?:
>>>>
>>>> <map:serialize type="{1}"/>
>>>>
>>>> I solved the problem using a selector, but I would really like to do it
>>>> with {1}. Is it possible?
>>>>
>>>> Thanks for your help.
>
>
>
> ---------------------------------------------------------------------
> 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:
Posted by Joerg Heinicke <jo...@gmx.de>.
Marc Portier wrote:
> I think Resources might do it as well,
> matter off taste what you'll prefer probably...
>
> <map:resource name="serialize-typeX">
> <serialize type="typeX"/>
> </map:resource>
>
> # and more for each type...
>
>
> and then have <map:call resource="serialize-{1}" /> in your pipe
Ah, nice idea I didn't think of.
> see for more at
> http://wiki.cocoondev.org/Wiki.jsp?page=CleanerSiteMapsThroughResources
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?
Joerg
> -marc=
>
>
> Joerg Heinicke wrote:
>
>> In short: no. Selector is the right way to go.
>>
>> Joerg
>>
>> Ramsés Morales wrote:
>>
>>> Hi.
>>>
>>> I would like to do sitemap substitution to the type attribute of the
>>> serializer from the wildcard matcher. I get this error:
>>>
>>> Type '{1}' is not defined for 'serialize'
>>>
>>> That means I can't select dynamically the serializer with this syntax?:
>>>
>>> <map:serialize type="{1}"/>
>>>
>>> I solved the problem using a selector, but I would really like to do it
>>> with {1}. Is it possible?
>>>
>>> Thanks for your help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re:
Posted by Marc Portier <mp...@outerthought.org>.
I think Resources might do it as well,
matter off taste what you'll prefer probably...
<map:resource name="serialize-typeX">
<serialize type="typeX"/>
</map:resource>
# and more for each type...
and then have <map:call resource="serialize-{1}" /> in your pipe
see for more at
http://wiki.cocoondev.org/Wiki.jsp?page=CleanerSiteMapsThroughResources
-marc=
Joerg Heinicke wrote:
> In short: no. Selector is the right way to go.
>
> Joerg
>
> Ramsés Morales wrote:
>
>> Hi.
>>
>> I would like to do sitemap substitution to the type attribute of the
>> serializer from the wildcard matcher. I get this error:
>>
>> Type '{1}' is not defined for 'serialize'
>>
>> That means I can't select dynamically the serializer with this syntax?:
>>
>> <map:serialize type="{1}"/>
>>
>> I solved the problem using a selector, but I would really like to do it
>> with {1}. Is it possible?
>>
>> Thanks for your help.
>
>
>
> ---------------------------------------------------------------------
> 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:
Posted by Joerg Heinicke <jo...@gmx.de>.
In short: no. Selector is the right way to go.
Joerg
Ramsés Morales wrote:
> Hi.
>
> I would like to do sitemap substitution to the type attribute of the
> serializer from the wildcard matcher. I get this error:
>
> Type '{1}' is not defined for 'serialize'
>
> That means I can't select dynamically the serializer with this syntax?:
>
> <map:serialize type="{1}"/>
>
> I solved the problem using a selector, but I would really like to do it
> with {1}. Is it possible?
>
> Thanks for your help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org