On Fri, 8 Feb 2002, Vadim Gritsenko wrote:
Well, I still solve inwards flows with two pipelines:
<map:match pattern="in-pipe">
<map:generate type="stream"/>
<map:transform type="save-to-xmldb">
<map:parameter name="node" value="/page/content"/>
</map:transform>
<map:serializei type="/dev/null"/>
</map:match>
<map:match pattern="in">
<map:generate src="cocoon:/in-pipe"/>
<map:transform/>
<map:serialize/>
</map:match>
The first pipeline represents the "input" pipe and can be protected in a
<pipeline internal-only="true">
pipeline. This "in-pipe" pipeline has what ever generator you need to
get to data comming in. For XML data send by a client I use the
StreamGenerator and use a custom Transformer to save the payload where
ever I need to have it (sure you can generalize those transformers to be
configurable, etc.) In the sample above I use a transformer capable to
select a node or node set (/page/content) out of the SAX stream
generated and save it into a XML db. It will leave a status in the SAX
pipe.
The second pipeline represents the "out-pipe" to give a response to the
client. It will prepare the response using a xslt transformer.
Sure you can combine those two pielines as separation in this specific
context doesn't make sense. But I wanted to make sure you distinguish
the input-pipeline from the output-pipeline.
So, you can have whatever kinds of storing components you
need implemented as a transformers. If the request payload is not xml
you need to do the storing at the generator level.
I don't think it's a big deal to come up with simple transformers and
generators to accomplish our needs but one for sure is that you
don't get true symmetry because the current sitemap always needs to
have a serializer at the end of a pipeline even it is never used (as in
all "internal-only"pipelines).
Giacomo
> Hi all,
>
> Preamble: I do remember we had talks about inward flows, etc... Then
> somebody (sorry, already forgot who it was) wrote about transformer
> which writes file as a side effect... Then Kinga proposes to add
> handlers reacting on input stream/documents... And recently I have got
> an idea that it should be quite an elegant way to handle all this if
> Cocoon is designed symmetrically: whatever abstractions we have to
> handle outgoing flow, let apply to the in-flow.
>
> First of all, we already (almost) have symmetry in pipelines: generators
> are symmetrical to serializers. Generators are able to produce XML
> content out of almost anything we can think of: physical file, HTTP
> resource, SQL database, XMLDB database, incoming request, etc.
> Unfortunately, serializers are somewhat limited comparing to the
> generators: the only out option we have is output stream. Let's expand
> this to the other sources as well. Then we can have, say, file
> serializer. Coupled with the ability of Sources to handle input streams,
> one can save XML stream into file, XMLDB, and other sources were
> protocol handler exists.
>
> Second. Now Cocoon perfectly handles aggregation, both on sitemap level
> and using aggregated transformers. But what we have opposite to the
> aggregation? Nothing. Let's add separation notion: result will be
> several SAX streams. Every stream will have a destination pipeline. This
> pipeline will be retrieved by "separator", and generator of the pipeline
> will be replaced by the "separator" which will feed SAX events into this
> pipeline. As you see, it is same mechanism aggregator employs but
> reversed.
>
> Third. To top all this, symmetrical component is to be developed to the
> X/C Include transformers. As "separator", it will extract parts of the
> stream and send them to the other pipelines.
>
> At last, let's consider an example. Let it be some request from the user
> to perform modification of the XML resource stored in the file (poor
> man's CMS ;)
>
> <!-- inflow internal -->
> <map:match pattern="get-data">
> <map:generate src="data.xml"/>
> <map:serialize type="/dev/null"/>
> </map:match>
>
> <map:match pattern="get-mods">
> <map:generate type="request"/>
> <map:transform src="request2data-mods.xsl"/>
> <map:serialize type="/dev/null"/>
> </map:match>
>
> <!-- main -->
> <map:match src="update">
> <map:act type="validate-user-input">
> <map:aggregate>
> <map:part src="get-mods" element="mods"/>
> <map:part src="get-data" element="data"/>
> </map:aggregate>
> <map:transform src="apply-mods--return-data-and-result.xsl"/>
> <map:transform src="add-index-update.xsl"/>
> <map:transform src="add-news-page-update.xsl"/>
> <map:separate>
> <map:part src="put-data" element="data"/>
> <map:part src="update-index" element="index-update"/>
> <map:part src="update-news" element="index-update"/>
> <map:part src="update-result" element="result"/>
> </map:separate>
> </map:act>
> </map:match>
>
> <!-- outflow internal -->
> <map:match pattern="put-data">
> <map:generate type="/dev/null"/>
> <map:serialize type="file" src="data.xml"/>
> </map:match>
>
> <map:match pattern="update-index">
> <map:generate type="/dev/null"/>
> <map:transform type="lucene"/>
> <map:serialize type="/dev/null"/>
> </map:match>
>
> <map:match pattern="update-news">
> <!-- ... -->
> </map:match>
>
> <map:match pattern="result">
> <map:generate type="/dev/null"/>
> <map:transform type="result2html"/>
> <map:serialize type="html"/>
> </map:match>
>
> PS: /dev/null: Currently, aggregator ignores serializer. That's to show
> that this is the dummy serializer.
>
>
> Hope this makes some sense and can be a start for a good discussion :)
>
> Vadim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
