From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
> Nicola Ken Barozzi wrote:
>
> > It seems that the dual nature of the processing in Cocoon is starting to
get
> > tested by sensible argumentations.
>
> I'm sorry, Ken, but I don't get your point about this 'dual nature', can
> you elaborate more?
Cocoon has
Event Pipeline <-> Stream Pipeline
IMHO it's not *stricly* necessary (as theory goes) to have an event
pipeline, and the fact that Actions are not so "pure" stems from the fact
that it makes the Event Components bleed into the original pure Pipeline
arena.
For example, instead of selecting between two pipelines and generating from
the choosen one, I can generate from both and filter only the relevant tags.
Not auspicable, but possible.
You can use Actions to act on the request (event pipeline), or you can use
the RequestGenerator and have a side-effects Transformer do the same action.
You can use some sort of Dispatching instead of Matching.
Since there is a possibility in Cocoon to do things in at least two ways
because of this, sometimes it happens that it comes natural to think that
there needs to be a pure duality between the two pipelines that now lacks.
Selector : Redirection or Rerouting
Action : Side-Effect-Transformer
Matching: Dispatcher-Adapter
It *seems* that one could build a Cocoon without the pure Event Components.
Like one could write Java without primitive types, and use only objects.
But IMHO there is a big difference here.
We have the opportunity of separating the flow (events) from the pipelines.
How are these Pipe-aware Selectors, Dispatchers, Adapters and side-effect
Transformers going to fit with the future Flowmap+Sitemap Cocoon?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
