On Fri, 8 Feb 2002 12:21:38 -0500, "Vadim Gritsenko" <[EMAIL PROTECTED]> wrote:
> 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. This makes a lot of sense, although what you describe is more like a pass-through transformer, which in the process has some side-effect actions. I'm not sure the best name for it is a serializer, but I don't have a better one. > 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 ;) > > [snip] > > <!-- 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> > > [snip] I agree with Sylvain's comment that the "src" attribute of map:part should be called instead "dest". What is the meaning of the "element" attribute? Can I extract any element from the document using an XPath expression (a simplified one may work too)? E.g. I'd like to be able to extract arbitrary elements from the SAX stream, not only top level ones. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
