cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [C3] Refactoring the SAX module
Date Wed, 18 Feb 2009 18:42:39 GMT
Carsten Ziegeler wrote:
> Hi,
> as part of COCOON3-22 I've refactored the whole SAX module and removed a
> lot of classes :)
> Before committing these changes I would like to discuss them (I can
> provided a patch but not sure if this works).
> Ok, the aim is to reduce the number of interfaces and abstract classes
> as much as possible.
> The o.a.c.sax packages contains
> - SAXPipelineComponent - the marker interface for all sax components
> - AbstractSAXGenerator, AbstractSAXSerializer, AbstractSAXTransformer
>   - the base classes to simplify implementation of these components
> - AbstractSAXProducer - base class for AbstractSAXGenerator and
>   AbstractSAXTransformer
> That's it - this creates imho a clean package and provides a good base
> for implementing own sax based components.
> Ok, I left o.a.c.sax.component the way it is atm (of course adapted the
> implementations)
> And o.a.c.sax.util only contains TransformationUtils and XMLUtils.
> The former adapter class in this package is replaced by SAXPipe from
> cocoon-xml (our 2.2 subproject). I'Ve added a copy of this class to
> cocoon-sax for the moment to not rely on a snapshot of cocoon-xml here.
> I also fixed javadocs and some bugs in the implementations :)
> I know that these changes will brake the symmetrie between the other
> implementations (Stax mainly) - but on the other hand it gives a nice
> and easier structure to implement components. People comming from 2.x
> who want to implement a component just pick up AbstractXYZ as a base and
> are done. And as these abstract classes are deduced to the minimum it's
> imho much easier to understand what's going on.

The feedback of our student group was rather the opposite. I'm pretty
sure that it helps to understand Cocoon 3 if all different pipeline
component implementations follow the same logic.

But of course my "survey" isn't really scientific ...

> I would go one step further and also remove the AbstractSAXProducer
> class and copy the code to the two using classes to make the hierarchy
> even simpler. 

TBH, I don't like duplicating this code in general and also in this
particular case because I don't see any benefit because people will use
AbstractGenerator/Transformer anyway.

> But that's not a must :)

thank god ;-)

> So, what do you think?

I'm not fully convinced yet. I will have a look at it again when I can
apply the patch and can build Cocoon. I have some (internal) code that
uses cocoon-sax and I want to understand all effects.
I'm also preparing a project proposal (GSoC, Vienna-based student
groups) about "Cocoon profiling" which relies on Spring AOP and I have
to think about the influence of not having SAXConsumer and SAXProducer

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message