Hi Joerg,
>> map:call does not work the same way as map:redirect-to does not work
>> because the steps before are not executed. Both must be the first and
>> only
>> statements in a map:match.
[...]
> fortunately the above is not true ;-)
>
> <map:call resource="resourcename"/> is a sitemap internal redirect for
> reusing pipeline fragments and so you can do first steps of a pipeline on
> another place than the resource.
>
> See also <map:resource/>.
I hear you saying this but when I try this
<map:resources>
<map:resource name="chunk">
<map:read src="work/{service}/index.html" mime-type="text/html"/>
</map:resource>
</map:resources>
and have a pipeline
<map:pipeline>
...
<map:transform type="xslt" .../>
<map:call resource="chunk">
<map:parameter name="service" value="{1}"/>
</map:call>
</map:pipeline>
It shouldn't be a problem being inside a selector? In the generation phase
of the pipline I get log records so I can see if the pipeline is really
executed completely.
And thus I can really see that immediately the resource is called and the
generation and transformation is definitely not executed!
Could it be that the behaviour changed after Cocoon 2.0.4 that I'm using?
The problem seems to be that the called resource is treated as if the
content is part of the calling pipeline. That means that I cannot use a
generator or read after a transformer. I tried exchanging the above read
with a <map:generate/> and <map:serialize/> and got a error that the
generator is already set in the pipeline.
I think this restriction is bad in this case. The transformer does not
create any output (docbook chunked HTML generation into files), therefore
it would not be a problem to have a generator afterwards. And a called
resource should behave like a sub-pipeline which it definitely does not at
the moment. Instead it behaves like a macro.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
