> From: Daniel Fagerstr�m [mailto:[EMAIL PROTECTED]]
<snip/>
> I'd love to have a Multiplexer component in Cocoon. I'd like Cocoon
> develop to the point where you can build webapps as easy and
> as elegant
> as you can build webpublishing today.
Right on!
> A selector choose _one_ of several processing paths for the input
> stream, while IIUC a multiplexer (at least conceptually),
> make several
> copies of the input stream, put each copy in a xpath-based
> filter that
> takes out a part of the stream and send it to a sub-pipeline,
> and in the
> end the filtered and processed streams are recombined to one single
> stream. IMO these are to different concern ares and I can't see any
> advantages in combining it to one component.
Don't know about those implementation details, but you're right,
multiplexing fulfills a different need, for which I aim to contribute my
own little monster soon, which unfortunately uses caching instead of
true event forwarding.
>Yes, I'm aware
> that you can
> do pipe-aware selection in a multiplexer by making the
> filter xpaths
> mutually exclusive, so that only one of the sub-pipes are used:
>
> <multiplex>
> <part xpath="a and not(b) and not(c) and not(d)">
> <!-- sub pipe -->
> </part>
> <part xpath="not(a) and b and not(c) and not(d)">
> <!-- sub pipe -->
> </part>
> <part xpath="not(a) and not(b) and c and not(d)">
> <!-- sub pipe -->
> </part>
> <part xpath="not(a) and not(b) and not(c) and d">
> <!-- sub pipe -->
> </part>
> </multiplex>
> I fail to find that particular usage of multiplexing elegant.
Doesn't exactly put the best face on it ;)
I agree that this use is a hack, but I was imagining more trivial cases:
<multiplex>
<part xpath="/output/noresults" src="cocoon:/noresultspage" />
<part xpath="/output/results" src="cocoon:/resultsview"/>
</multiplex>
Not so hideous anymore, is it?
> It also
> seem higly non-trivial to write a multiplexer component that is
> efficient in the above scenario. Negations in xpaths are
> somewhat tricky
> beasts: <retoric-question>how much of the input stream do you need to
> scan (and buffer) before you know that "not(//elem)" is
> true?</retoric-question>
Agreed.
> IIRC there were never any concrete design propopsals in the
> multiplexer
> discussion and there is an implementation (although with some rough
> edges) of a pipe-aware selector, IMHO that is a not
> completely neglible
> difference between the two proposals ;)
I know :/ That's why I was trying to stir the pot, and help any way I
can.
> <snip/>
> > To be honest, I haven't looked at Daniel's new selection code,
>
> Please take a look at it, it is not much code at all, it is quite
> straight forward and I even added a few cryptic comments and wrote a
> README-file to the code ;)
I will, I promise.
> <rant>
> I'm somewhat amused, some of you guys seem obsesed by DOM hatred. I
> really appriciate your work for exorcising DOM from web
> publishing, but
> I think webapps are somewhat different, and I have written
> quite a lot
> about in what way on the list. With a few exceptions (thank
> you Stefano
> and Ivelin) all response I get is: he have used the D-word,
> Thou shall
> never use DOM in Cocoon. ;)
> I don't remember who wrote that: "premature optimzation is
> the root of
> all evil".
> </rant>
Rant well taken :) Thank you all for opening my eyes.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
