cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [RT] Cocoon Symmetry (short :)
Date Fri, 08 Feb 2002 20:57:29 GMT
> From: giacomo [mailto:giacomo@apache.org]
> 
> 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.)

I'm aware of such possibility, and it does not seem to me as a generic
and flexible enough way, not to tell that it's not goes well with the
overall Cocoon beauty. In the preamble I mentioned this - Transformer
with side effect - way.


> 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.

They are distinguished well: input pipelines are on the top of the
sample, output - on the bottom; input pipelines do not have serializers,
output pipelines do not have generators; both of them are internal-only
by semantic and can be protected by internal-only="yes" syntax.


> So, you can have whatever kinds of storing components you
> need implemented as a transformers.

Yes. But for some reason they better look like serializers.


> If the request payload is not xml
> you need to do the storing at the generator level.

Or even better: serializer level.


> I don't think it's a big deal to come up with simple transformers and
> generators to accomplish our needs

Yes, you can overcome lack of separation concern by adding all the
needed transformers.

> but one for sure 

Don't be so sure, 'cause...

> 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).

...there is a true symmetry here: output pipeline always needs to have a
generator at the beginning of a pipeline even it is never used.

Let's continue :)

Vadim


> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message