cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [C3] Pipeline component event types
Date Tue, 13 Jan 2009 18:56:43 GMT
Steven Dolg wrote:
> Carsten Ziegeler schrieb:
>> Wouldn't it be better/easier to have a sax pipeline, a dom pipeline, a
>> stax pipeline, perhaps sharing a common interface?
> From my point of view:
> Currently the user must know which components he needs (as in "I want to
> process XML and I'd like to do it with StAX").
> As soon as he know this, he just selects the components (either existing
> or created) but them in *any* pipeline (caching/noncaching/etc.)
But the user needs to choose the same xml transportation for all
components in the pipeline, being it directly or through wrappers.

> If there were multiple, content-specific Pipelines he still needs to
> know which components, but also which type of Pipeline.
> If he feels the need to change to SAX (so a switch in the "event type" -
> IMO a sub-optimal term, since not every component actually passes nice
> events like StAX does) he also needs to change the Pipeline.
> This may seem easy now, but imagine a larger system. Changing the
> pipeline type can be challenging there.
>From what I understand so far in this discussion this simple switching
does not work (or is not intended to be implemented - which is fine for
me). So besides from switching the pipeline implementation you have to
switch all components or at least add matching wrappers around them.

> And what about automatically generated pipelines (e.g. the sitemap).
> This will be so much harder as you have to collect and analyze all
> components first before you can actually build the pipeline to use.
I think you have to do this anyway - as not all components fit together.

> Defining a common interface for different pipeline types does not really
> change this.
> If the common interface is sufficient for handling and operating the
> pipeline they are exchangable (from the callers point of view) and
> provide the same environment we have now.
> If the common interface is not sufficient for handling and operating the
> pipeline it is merely a marker interface and it probably wouldn't make
> much difference. (Although it is still useful for declaring parameter
> types, etc.)
> I may be biased here ;-) but I have yet to see the benefits of different
> pipeline types...
:) I have the same feeling for the opposite...if I can't just mix dom
with sax and maybe stax, then why following this generic approach?

Hmm, maybe generics could help?
So we have something like:
public interface Pipeline<T extends PipelineComponent>

and have sub interfaces for PipelineComponent for sax, dom, stax?

This ensures to have a single implementation but gives compiler time checks.

Carsten Ziegeler

View raw message