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) But we have Pipeline, Consumer, Finisher, Producer, Starter, XMLConsumer, XMLProducer, followed by a bunch of abstract classes - and 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. So please, don't consider this as a critics on the whole concept. It's just about minor improvements if at all. Carsten -- Carsten Ziegeler [email protected]
