Grzegorz Kossakowski schrieb:
Steven Dolg pisze:
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 necessar
Steven Dolg pisze:
> 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 i
Peter Hunsberger pisze:
>
> 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 Cocoo
On Tue, Jan 13, 2009 at 12:00 PM, Carsten Ziegeler 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 PipelineComp
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
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 configuration);
>
>
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
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>> TBH I'm still not fully convinced of the parameters approach. If
>> none is faster than me I will prepare patches for both solutions so
>> that we see what it means at code level.
>>
>> I would also be interested in what others think about the
Reinhard Pötz pisze:
>
> TBH I'm still not fully convinced of the parameters approach. If none is
> faster than me I will prepare patches for both solutions so that we see
> what it means at code level.
>
> I would also be interested in what others think about the two solutions
> or maybe there a
Reinhard Pötz wrote:
> TBH I'm still not fully convinced of the parameters approach. If none is
> faster than me I will prepare patches for both solutions so that we see
> what it means at code level.
>
I can write a patch - but I would like to wait for Steven's changes first.
Carsten
--
Carste
Carsten Ziegeler wrote:
> Carsten Ziegeler wrote:
>> Reinhard Pötz wrote:
>>> I want to provide a SAX buffer to the pipeline and the serializer just
>>> passes the SAX events to it.
>> Ah, ok.
>>
As the output stream is a runtime object for the finisher it should be
treated like other obj
Carsten Ziegeler wrote:
> Reinhard Pötz wrote:
>> I want to provide a SAX buffer to the pipeline and the serializer just
>> passes the SAX events to it.
> Ah, ok.
>
>>> As the output stream is a runtime object for the finisher it should be
>>> treated like other objects of this kind (the src url f
Reinhard Pötz wrote:
> I want to provide a SAX buffer to the pipeline and the serializer just
> passes the SAX events to it.
Ah, ok.
>> 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 examp
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
>> res
On Mon, Jan 5, 2009 at 2:36 AM, Carsten Ziegeler wrote:
> Reinhard Pötz wrote:
> 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
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 impo
Carsten Ziegeler wrote:
> Reinhard Pötz wrote:
>> Reinhard Pötz wrote:
>>> Carsten Ziegeler wrote:
>>>
There is a slight overlap between the serializer and the result - for
example if you want to get java objects out of the pipeline, you might
want to use a special serializer. So may
Reinhard Pötz wrote:
> Reinhard Pötz wrote:
>> Carsten Ziegeler wrote:
>>
>>> There is a slight overlap between the serializer and the result - for
>>> example if you want to get java objects out of the pipeline, you might
>>> want to use a special serializer. So maybe we can merge the two?
>> I wa
Reinhard Pötz wrote:
> Carsten Ziegeler wrote:
>> Reinhard Pötz wrote:
>>> But still there is one limitation that has bugged me several times: The
>>> result of all pipelines is that they write something into an output stream.
>>> That's the original use case for pipelines used in servlet environme
Hi Reinhard,
thanks to mentioned me :P I like your proposal and, indeed, is what we
start thinking when I submitted the Digester Finisher[1] patch; in the
testcase, there's the demonstration that the Finisher had to be
"forced" using a null OutputStream - otherwise the Pipeline couldn't
start - the
Carsten Ziegeler wrote:
> Reinhard Pötz wrote:
>> But still there is one limitation that has bugged me several times: The
>> result of all pipelines is that they write something into an output stream.
>> That's the original use case for pipelines used in servlet environments
>> and probably true in
Reinhard Pötz wrote:
> But still there is one limitation that has bugged me several times: The
> result of all pipelines is that they write something into an output stream.
> That's the original use case for pipelines used in servlet environments
> and probably true in many cases but not in all.
>
Triggered by some discussions that Steven and I had with our students we
were thinking again about the pipeline API. Compared to previous
pipeline implementations we already made one improvement by making the
pipeline unaware of the data that flows between its components. This
means that the Cocoo
23 matches
Mail list logo
