Carsten Ziegeler schrieb:
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.
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 :)
Just random thoughts (and I must admit I haven't thought about the
changes in detail):
* Extending some abstract classes is all that was necessary all the
time. Getting rid of some of the interfaces implemented by those
abstract classes actually changes nothing for a developer but makes
things like AOP (at least sometimes) a lot harder.
* Forcing a developer to add his classes to our class hierarchy
eliminates any possibility of building his own class hierarchy and
implementing the interfaces directly (this might not be necessary in the
most cases, but I see no reason to eliminate this option completely)
* Duplicating code to make the class hierarchy "even simpler" (whatever
that means) seems like a pretty bad idea IMO. Code duplication has
almost never done anything good for me (besides being quick & dirty -
which is usually just dirty and not quick at all if you intend to work
with the code for quite some time).
* Replacing the SAXConsumerAdapter with the SAXPipe means it cannot be
used as a surrogate destination for a SAXTransformer or adapter for a
ContentHandler (which was the intention behind this class) - so how can
it actually replace it (or has the contract between SAXProducer and
SAXConsumer changed)?
* Without any more detail it's impossible to fathom the
meaning/implications of those changes.
So is this about having a developer still extending
AbstractSAXGenerator, AbstractSAXSerializer, AbstractSAXTransformer
(which all exist now) but making the class hierarchy above (as in
towards java.lang.Object) less deep/wide by removing interfaces/abstract
classes implemented/extended by those classes?
And sorry for asking again, but what's the rationale behind "reduce the
number of interfaces and abstract classes as much as possible"?
Steven
So, what do you think?
Carsten
