cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <steven.d...@indoqa.com>
Subject Re: [C3] Caching
Date Tue, 23 Dec 2008 12:18:45 GMT
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
>   


Mime
View raw message