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] Refactoring the SAX module
Date Tue, 17 Feb 2009 21:06:28 GMT
Steven Dolg schrieb:
> 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)?
Just realized there is no SAXConsumer any more.
So how does the linking between SAX components work?
AbstractSAXProducer will accept an AbstractSAXTransformer or 
AbstractSAXSerializer? Or operate directly against ContentHandler (which 
would explain the SAXPipe thingy)?

> * 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
>>   
>


Mime
View raw message