Carsten Ziegeler schrieb:
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.
I don't think I understand what you mean by "same xml transportation".
Currently creating and executing a pipeline looks like:
Pipeline pipeline = ...;
pipeline.add(new StAXGenerator(inputURL));
pipeline.add(new StAXTransformer(myParameter));
pipeline.add(new StAXSerializer();
pipeline.setup(outputStream);
pipeline.execute();
It is the same when using SAX (except different components, of course)
or when processing any other type of data (I think I should really go
and build that Imaging module...).
Again I have the feeling that some concepts that Cocoon has for years
now (Pipelines look like Generator -> Transformer -> Serializer; make
sure the sitemap makes sense; know what the components actually do) are
all of a sudden too complicated for any user to apply them safely
without reading the source code.
But that may be just me...
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).
This simple switching of components works right now!
While creating the StAX components we often exchanged the components
(again all of them, not individual ones - SAX and StAX are not
compatible without adapters)
to compare the results from SAX and StAX.
So besides from switching the pipeline implementation you have to
switch all components or at least add matching wrappers around them.
I'm not proposing content-specific pipeline implementations.
IMO demanding that the user also selects the correct pipeline type for
his choice of components - that need to be compatible with each other
*and* the pipeline - is actually more than just demanding that he
chooses components that are compatible with each other and guaranteeing
that any (correctly implemented) pipeline will do the job.
Since this is about making it easier for the user, I think content
specific pipelines actually cause the opposite effect, because it adds
another element to be considered.
On top of that it also makes introducing new content types harder since
one has to provide a pipeline implemementation (and possibly interface),
too.
The components need to communicate with each other nonetheless. The
additional "Are you compatible with me?" check is fairly easy compared
to that (for StAX that are 3 lines of code in one abstract base class).
Being able to use the same Pipeline implementations (even the rather
sophisticated asynchronous caching pipeline) has saved us probably days
of work and that compatibility check took no more than 5 minutes once
the interfaces for the components (which we needed anyway) were defined.
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.
Currently we have no need to select the pipeline specifically for the
components to be used (in fact the sitemap builds the pipeline before
even knowing the components).
If the components are really not compatible this will be detected before
the pipeline is actually executed (in the setup phase).
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.
Well that would be nice of course.
But so far not working solution/prototype has been made available (or
did I simply miss it?).
And those that have merely scratch surface IMO.
There are still things like component order: Generator, Generator,
Transformer, Serializer, Generator is clearly not a valid pipeline, even
if all components are actually using the same technology.
Carsten
