> From: giacomo [mailto:[EMAIL PROTECTED]] > > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
