cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject [C3] Refactoring the SAX module
Date Tue, 17 Feb 2009 19:47:51 GMT

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

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

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.

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. But that's not a must :)

So, what do you think?

Carsten Ziegeler

View raw message