cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: [status & RT] design challenges
Date Fri, 05 Apr 2002 17:14:34 GMT
From: "Stefano Mazzocchi" <>

> My impression is that pipe-aware selection is 'forcing' metadata to pass
> 'thru' the pipeline while it doesn't really make sense to do so.
> So, IMO, there must be some transformers that obtain the required
> selection information from the pipeline, place it somewhere else
> (probably someplace in the object model) and have the selectors look at
> those 'parallel signals' without having to mess with the pipeline.

Bud don't Selectors get to run *before* Transformers.

This is the whole point it seems.
It's not a matter of how, but when.

Selectors can run after Transformers only if another pipeline is called, and
this will basically force you to use the flow pipeline for this, since in
fact it's flow we're talking about.

As I see it, Matchers, Selectors and stuff can easily be put all in the flow
part, but this makes Cocoon too "procedural".

An easy tip: if you serve web pages, use the pipeline only. If you need to
make complex decisions and procedures on the flow, use the flowmap.

> So, I restate my -1 on pipe-aware selection and I propose the creation
> of a 'parallel transport layer' between components that is based on
> objects and not SAX events.

Could you elaborate more on this?

I think it's something like having a request object, but seen as a parallel

I'm +1000 on this, since it finally fullfilles the original intention we had
with Cocoon2 pre-alpha to have a parallel metadata pipeline, where there are
also notifications.

Gee, it seems that you saw right before needing it! :-O


Nicola Ken Barozzi         
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message