Grzegorz Kossakowski schrieb:
Reinhard Pötz pisze:
Thanks Grek! But there is no need to hurry because neither Carsten nor I
will work on this until Steven has finished his refactorings.
Actually, for me there was a hurry as another series of exams in coming and I
wanted to contribute something useful
before February.
Your problem made me to analyze Cocoon3 Pipeline API very carefully and think
about it for a while. What I found rather
strange is PipelineComponent interface, see:
public interface PipelineComponent {
void setConfiguration(Map<String, ? extends Object> configuration);
void setup(Map<String, Object> parameters);
void finish(Exception exception);
}
Why I think this interface is strange (and confusing)? Becuase it does not deal
with the most important aspect of
PipelineComponent: that it processes something and that it can be combined with
other components. The most important
aspect is neither configuration nor setup of a component.
Configuration and setup is clearly not the most important aspect of a
pipeline component.
But AFAIK interfaces are not designed by what is most important or not,
but by what is common to the implementating classes and by what is
really necessary for the caller of that interface.
From that point of view configuration and setup (and yes, those names
are not ideal - suggesstion are always welcome...) are very valid
candidates for that interface.
It is the common basis of *all* pipeline components.
This is the most basic interface for any pipeline component - no matter
if it is a Serializer, Generator, Transformer, uses SAX, StAX, Images,
Beans, ...
I seriously wonder what methods for content processing and component
linking you are missing at that level?
As this is basically a marker interface (with those 3 methods that are
common to all components) a user won't have to deal with it.
Even a developer implementing new components hardly ever gets in contact
with it, as he will usually deal with the Starter/Finisher,
Producer/Consumer level above PipelineComponent.
I understand that this concept is quite a bit different than Cocoon 2.2
and is almost completely undocumented at this time, too.
But I seriously doubt that selecting interfaces randomly and questioning
their usefulness is really good approach...
I started to think that we will have such problems like the one mentioned in
this thread as long as we don't address
issues with PipelineComponent.
I've decided to experiment with the code (after analyzing the problem on a
paper) and you can see results here:
http://github.com/gkossakowski/cocoonpipelines/tree/master/src/org/apache/cocoon/pipeline
This code proves only one thing: that I failed to address an issue mentioned
above. What I'm interested in is if others
share my concerns about PipelineComponent interface (and Pipeline itself) and
if you also see a relation to problem with
pipeline result?
