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
anymore.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
________________________________________________________________________
