cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@apache.org>
Subject Re: processing serializer output on server
Date Mon, 06 May 2002 21:10:23 GMT
From: "Horst Rutter" <horu@objectleague.com>

> Nicola,
> What do you mean by "the Generator of the second calls the output of the
first one"?
> Are you refering to a map:call or a "cocoon:/smth" parameter?
> Could you please give a short example?
>
> Here is what I have right now:
> Also to correct myself I am dealing with one pipeline containing two
<map:match> fragments rather than 2 pipelines.
>
> <map:pipeline>
>   <map:match pattern="generatepdf">
>     <map:generate src="test.fo"/>
>     <map:serialize type="fo2pdf"/>
>   </map:match>
>   <map:match pattern="sendpdf">
>     <map:generate type="serverpages" src="sendmail.xsp">
>       <map:parameter name="email-attachment" value:"cocoon:/generatepdf"/>
>     </map:generate>
>     <map:serialize/>
>   </map:match>
> </map:pipeline>

Looks ok to me :-)

> I could also use an action (SendmailAction) instead of the xsp but that
does not ease the problem.
> I'd still have to pass on or call in to generatepdf and put that into a
parameter for the action.

Which "problem"?

> BTW I believe a construct similar to action-set could help in a situation
like this where
> <map:pipeline-set>
>     <map:pipeline id="first" ... </map:pipeline>
>     <map:pipeline id="second" ... </map:pipeline>
> </map:pipeline-set>
> always ensures the contained pipelines get executed in the order defined
and always pass
> on the output of the previous one as the input for the next in sequence.

Above you are not using the result of the first as an entry to the second.
The entry of the second is an XSP.
This is done by something like:
   <map:match pattern="sendpdf">
     <map:reader type="myzipsendoranythingelsereader"
                              src="cocoon:/generatepdf"/>
       ...

> Further elaborating we could also have something similar for ensuring
*all* matching <map:match> fragments in
> a pipeline get processed sequentially for instance by having a parameter
on <map:pipeline>

The generators have a source attribute to specify where to get the stuff to
process.
The chaining you are talking about is done by transformers usually...
But in you case you want stream-chaining/filtering, which Cocoon is not made
to do.

We could build it in, but there is not a big need; chaining requests between
sitemaps like above is the easiest way, since there is not more that a stage
usually.
Remember that it's a very costly processing to do.

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message