> From: giacomo [mailto:[EMAIL PROTECTED]] > > On Wed, 6 Mar 2002, Stefano Mazzocchi wrote: > > > Michael Homeijer wrote: > > > > > > Hi Stefano, > > > > > > Could you please have another look at the solution described by Bruno > > > Dumon > > > in the mailing list and comment on it. > > > I'd really like to know what you think about it. > > > > > > It seperates the small incoming parts of data from the outgoing flow, > > > doesn't change any cocoon interfaces, and you will be able to integrate > > > results from processing incoming data into the pipeline again. > > > > Bruno wrote this example: > > > > <map:act type="FetchAndStoreXml" src="cocoon:/something"> > > <map:parameter name="storeAs" value="foo"> > > </map:act> > > <map:select type="XPathSelector" > > <map:parameter name="xmlName" value="foo"> > > <map:when test="/some/node = 'xyz'"> > > <map:redirect-to uri="somewhere"> > > </map:when> > > <map:otherwise> > > <map:generate type="XSLTGenerator" src="stylesheetsource"> > > <map:parameter name="xmlName" value="foo"> > > </map:generate> > > <map:serialize/> > > </map:otherwise> > > </map:select> > > > > I have the feeling that this is a (admittedly brilliant!) hack. > > > > If we believe that Selectors should have access to the pipe flow, we > > must change the interfaces, not create hacks with what is already > > there... otherwise the system will be torn apart by these hacks (the > > maintenance cost of the above code is huge since it's hard to understand > > what it does simply by looking at it!) > > This is my perception. > > > > What do others think about this?
The more I read about "pipeline selectors" the less I like them (DOM tree building, re-streaming, ...)... However, don't you think that there is some overlap between these "sitemap selectors" and recently proposed "multiplexer"? Using DOM implementation of it (it is possible to have one), you will be able to evaluate XPath expressions and choose one of the several execution paths - or pipelines (follow the tail of "RE: is cocoon symmetry a holy grail?" for details about this "multiplexer"). What do you think about this? > > C'mon, without input I won't change anything. > > In fact I don't think we can change the Selector interface as it is > clearly stated what a Selector is and how it works (read: not a pipeline > component). It doesn't mess with the SAX event in a pipeline (also for > backwards compatability). I agree with Giacomo: let's leave Selectors as they are, messing with old and well-known interface does not feel right. Vadim > Maybe there needs to be other sematic in the sitemap to achieve what was > requested (honestly I have not had the need for such things so I don't > really care) > > Giacomo > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
