> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > Ovidiu Predescu > > 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,
I do not mean: add second out to the serializer, I do mean: let's allow serializer work not only on output stream, but also support other destinations (and other destination will replace output stream). > 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. There is a difference: serializer does not have a (SAX stream) result. Transformer always sends back SAX stream. > > 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". It's a minor thing :) > What is the meaning of the "element" attribute? Same as for <map:aggregate>: once this element is reached, all SAX events are forwarded to the corresponding pipeline (see also Kinga's emails: there are some commonalities with Dispatcher). > Can I extract any > element from the document using an XPath expression (a simplified one > may work too)? As I mentioned: CExclude/XExclude (trying to come up with symmetrical name for CInclude/XInclude) transformer may do this: once match is found, forward stream to specified pipeline. > E.g. I'd like to be able to extract arbitrary elements > from the SAX stream, not only top level ones. It is same as in aggregation: at sitemap level - only on root elements level, at transformation level - works on any arbitrary element. Vadim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
