On Tue, Jan 13, 2009 at 12:00 PM, Carsten Ziegeler <[email protected]> wrote: > Grzegorz Kossakowski wrote: >> 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. >> >> 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? >> > I agree that the PipelineComponent interface looks really strange. It's > absolutely not clear what the difference between setConfiguration and > setup is - so I think we need better names here. > > The finish method looks also strange as it gets an exception as a > parameter. The question is if a component should really now what > exception occured during a pipeline run or if a boolean is sufficient. > > Apart from that I think, the interface is the price we have to pay for > the flexibility we get. >
I guess part of the debate is whether it is worth defining some additional method, eg: CocoonOutput execute( CocoonInput genericInput) throws ?; or Object execute( Object genericInput) throws ?; I really can't see that the CocoonOuput and CocoonInput are anything more than marker interfaces and this of course means that more standard objects have to be wrapped so I think the second version is preferable. But that certainly doesn't buy you anything as far as pipeline contracts are concerned for traditional Java. However, I do think that perhaps this opens up some longer term possibilities for Aspect oriented inspection across the pipeline so maybe it is actually worth adding? -- Peter Hunsberger
