Carsten Ziegeler schrieb:
Reinhard Pötz write:
Agreed. How do you know what kind of wrapper do you need if you don't
know what kind of events components consume and produce?
My assumption is that the developer that uses the pipeline knows what he
does.
:) While this
Carsten Ziegeler wrote:
Reinhard Pötz write:
Agreed. How do you know what kind of wrapper do you need if you don't
know what kind of events components consume and produce?
My assumption is that the developer that uses the pipeline knows what he
does.
:) While this assumption *should* be
Reinhard Pötz pisze:
My assumption is that the developer that uses the pipeline knows what he
does.
This is rather good assumption. The problem I can see is that developer has to
check sources of each component in order
to know what he does as components type does not express what kind of
Steven Dolg wrote:
Carsten Ziegeler schrieb:
Wouldn't it be better/easier to have a sax pipeline, a dom pipeline, a
stax pipeline, perhaps sharing a common interface?
From my point of view:
Currently the user must know which components he needs (as in I want to
process XML and I'd like
Reinhard Pötz wrote:
The situation is similar to Spring which allows the wiring of components
that don't fit together. As long as I get proper error messages I don't
really have a problem with it.
Now, I think Spring config can be a nightmare, but that's a different
problem :)
Yes, proper
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 CocoonInput are
Carsten Ziegeler schrieb:
Steven Dolg wrote:
Carsten Ziegeler schrieb:
Wouldn't it be better/easier to have a sax pipeline, a dom pipeline, a
stax pipeline, perhaps sharing a common interface?
From my point of view:
Currently the user must know which components he needs (as
Grzegorz Kossakowski schrieb:
Reinhard Pötz pisze:
My assumption is that the developer that uses the pipeline knows what he
does.
This is rather good assumption. The problem I can see is that developer has to
check sources of each component in order
to know what he does as
Steven Dolg wrote:
I don't think I understand what you mean by same xml transportation.
Ah sorry, this was a try to find something better than event types.
Currently creating and executing a pipeline looks like:
Pipeline pipeline = ...;
pipeline.add(new StAXGenerator(inputURL));
Steven Dolg pisze:
It depends how you define being successful. I've managed to express
this rather simple idea but the code is horrible
thus I consider it as a failure.
Well cleaning up working code cannot be that hard - you haven't invested
years of time, have you ;-)
The problem is
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
Carsten Ziegeler pisze:
wouldn't work - and maybe this wouldn't even end in an exception. The
pipeline has no knowledge of the possible event types and which event
types are compatible. So how can it check the validity of this pipeline?
This is delegated to pipeline componets that has to
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
13 matches
Mail list logo
