Carsten Ziegeler schrieb:
Steven Dolg wrote:
Regarding the whole topic
In your first mail you wrote: "there are too many interfaces which might
confuse users"
Mind explaining what you mean?
Sure, see below :)
IMO a user won't have to deal with many of the interfaces at all - even
if (s)he uses the pipeline API directly (iow programmatically), not to
mention when using the sitemap.
Someone who actually deals with the Cocoon code shouldn't have too much
trouble - especially when comparing it to Cocoon 2.x.
IIRC this isn't the first time that someone said "Cocoon 3 is already
too complicated because of too many/much ..." (e.g. interfaces, modules,
complexity etc).
I think, I didn't say that (at least not directly) :)
I mean Cocoon 2.x is at least 5 times as much as Cocoon 3 - no matter
what kind of metric you use (I'm just guessing here, didn't actually
measure).
So how come a considerably smaller/simpler approach is suddenly too
complicated or too confusing?
Again, I was just trying to make the point that there are already a lot
of interfaces, abstract classes and classes. And I also said that given
the functionality we want, there might be no other way.
Comparing Cocoon 2 with the pipeline api is comparing apples with
oranges. I'm just talking about the pipeline stuff we have and without
further thinking one would expect four interfaces (a pipeline, a start,
an end and middle parts)
Actually that is all we have right now.
Pipeline and PipelineComponent. With PipelineComponent being
differentiated into Starter, Finisher and Consumer/Producer - what you
called the "middle parts". (Actually there is still a design flaw: the
consumer is no PipelineComponent, but that'll be corrected presently).
Consumer and Producer are separated into two interfaces, as to not
require special handling when linking the Starter with the second
component or the second to last with the Finisher.
I like to call these the "structural layer", because they define the
structure of any pipeline:
* first component is always a "Starter"
* last component is always a "Finisher"
* any number pairs of "Producer"/"Consumer" between them
Every (valid) pipeline is composed in this way - regardless of what
content or which implementation.
Thus these interfaces have no relation to anything that is content-based.
But that's also why we need additional layers, because otherwise the
pipeline would be specific for every type of content (which it should not)
But we have Pipeline, Consumer, Finisher, Producer, Starter,
XMLConsumer, XMLProducer, followed by a bunch of abstract classes - and
All the XML... interfaces are already the "content layer" (in this case
for SAX) on top of the "strcutural layer"
It defines how the components communicate with each other:
1. XMLConsumer is a ContentHandler and LexicalHandler
2. XMLProducer can accept an XMLConsumer and provide it with
appropriate data
Follow (basically) by AbstractXMLProducer (implementation of 2. from
above) and AbstractTransformer (AbstractXMLProducer + XMLConsumer).
The "content layer" is already beyond the scope of the Pipeline API
module - it does not care about this at all.
This is solely the domain of the pipeline components.
That's why the SAX layer should be removed asap from the Pipeline API.
even with a Cocoon 2 background, you might be a little bit lost as you
don't see a generator, transformer or serializer as an interface.
Now, all the stuff here is for good reason and makes sense, so I guess
we need all of this - and in the end it also makes sense to not use the
Cocoon 2 names. But it would be nice if we could keep this to a minimum
and perhaps take a look if we could reduce something somewhere or
perhaps rename something to make it even easier to use - now this is all
a little bit vague, I know, if I would have concrete ideas I would tell
them. It's just the feeling that what we have atm at least "looks" like
too much.
As Cocoon 3 was not available when I needed a simple pipeline
implementations and as I needed at that point something very quickly, I
wrote my own pipeline api and implementation which is just sax based -
and now I'm trying to map the functionality I have, to what we have in
C3 and it took me a little bit to find out what interfaces exactly I now
have to implement just by looking at all the names. But maybe it's just me.
Perhaps moving the sax stuff to another module, having the xml-util
module is already enough. Maybe renaming something like XMLConsumer to
SAXConsumer helps as well.
Absolutely!
With two types of XML components (SAX, StAX) this name is completely
ambiguous and must be changed (I prefer SaxConsumer).
This would also emphasize that the Pipeline API is designed to be
content-agnostic and SAX is merely one type of content it can handle.
StAX is the first step to add another content-type - well it's still
XML, but works completely different.
So please, don't consider this as a critics on the whole concept.
Not at all - I usually welcome all input!
I just have a hard time, when I struggle to get the actual point.
Trying to understand what you mean, I looked at some code and followed
the class/interface hierarchy.
And while doing so I found that some of this is rather strange and took
me moment to sort out.
And I think I know now what you mean.
But I guess it's mostly a problem with the names of the
classes/interfaces (like "AbstractTransformer" being actually an SAX
based Producer/Consumer) and mixing SAX with the Pipeline.
I suppose separating those two and changing some of the names it should
be alot better.
It's
just about minor improvements if at all.
I think it's actually a little bit more than that.
Seems like I was already so accustomed to the concept in my head that I
didn't even see, the implementation has become less clear that it could be.
So PLEASE keep on doing this!
And don't feel bad when my answers appear a little harsh - I rarely mean
it that way... ;-)
Steven
Carsten
