cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [c3] Pipeline results
Date Mon, 05 Jan 2009 08:36:56 GMT
Reinhard Pötz wrote:
> Yes and I don't think that there speaks anything against it: One
> serializer can produce one particular result type.
Yes, or maybe two (output stream and writer).

> The problem that I want to solve is that a pipeline can produce other
> results than OutputStreams which imposes an unnecessary limit or makes
> things ugly because you have to produce something that you don't need
> and use a hack to get out what you really want.
> I think we all agree on this.
Yes, definitly.

> The question we have to answer now is, how to we want to get access to
> the produced result. As pointed out before, I don't think that it is a
> good idea if you have to ask the finisher to get the result. If we do it
> this way, we would probably have to expose the finisher via the pipeline
> API. I'm not sure if that's the way to go.
Ok, so which use cases do we have? Apart from the io stuff the finisher
might return an arbitrary object. Obviously, there's a difference
between these two use cases: for the io stuff, the client of the
pipeline needs to provide an output stream (or writer) to the pipeline
(finisher). Whereas for the other use cases, no special object is needed
for the finisher, but the finisher just returns something.

Ok, so let's throw in some other ideas:
The pipeline interface has the execute method, we could change the
return type of that method from void to Object. So the execution of the
pipeline returns the result (if any).

As the output stream is a runtime object for the finisher it should be
treated like other objects of this kind (the src url for the file
generator for example etc.) which means it should be passed in through
the parameters for the finisher.

Carsten Ziegeler

View raw message