cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [c3] Pipeline results
Date Mon, 05 Jan 2009 16:21:45 GMT
Carsten Ziegeler wrote:
> 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.

I want to provide a SAX buffer to the pipeline and the serializer just
passes the SAX events to it.

> 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.

I'm not sure if I understand your idea: Do you propose to change the
interface this way?

setup(Map<String, Object> outputParameters,
      Map<String, Object> inputParameters);

The client of the pipeline API has to put the objects for the serializer
into the output parameters map and the serializer gets them passed so
that it can manipulate them?

The advantage compared to my proposed solution is that this way a
serializer could handle more than one output type. Right?

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message