> -----Original Message-----
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> Sent: woensdag 6 maart 2002 14:57
> To: [EMAIL PROTECTED]
> Subject: RE: Pipe-aware Selectors
>
>
> > 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?
>
I've looked at the discussion again and now I am beginning to understand.
You may have a point.
As I understand it, all possible paths data may flow through the pipeline
are setup when the pipeline is setup,
then the pipeline is executed. Based on the data in the pipeline it is
"routed" by the multiplexer into the right part of the pipeline.
I have the following situation:
(1) I have a form with data (requestgenerator),
(2) the data is validated by a validating transformer (in case of failure
see 5b)
(3) the data is transformed into xmldb transformer syntax (by xslt)
(4) the data is transformed by the XMLDBTranformer into Xindice
in case of success (result from XMLDBTransformer):
(5a) result from step 4 is aggregated with an xml:db query
in case of failure:
(5b) result from step 4 (or 2) is aggregated with result from step 1 (to get
the original data back into the form) and the result from an xml:db query.
(6) result is transformed and serialized into html
This is probably something to be solved by multiplexer. Maybe you can
explain how the sitemap for this problem would look?
Michael
>
> > > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
