cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: AbstractSAXTransformer
Date Sat, 08 May 2004 15:17:55 GMT
On 07.05.2004 09:56, Carsten Ziegeler wrote:

>>The ability to buffer is not obvious from the name. While 
>>it's implicite for the AbstractDOMTransformer it is not for 
>>AST. That's why I did not search for buffering inside it. 
>>Furthermore with recording into DOM it provides the same 
>>functionality like AbstractDOMTransformer - or even more as 
>>it allows to record document fragments.
> 
> I think, AbstractDOMTransformer is only a legacy transformer
> to easier port components from Cocoon 1.x.

Ok. What about deprecating it then - following our new guide lines of 
course.

>>Now does this not call for a refactoring? When writing my 
>>transformer I also found the transformer class hierarchy very 
>>confusing. First there should be a most simple 
>>AbstractSAXTransformer that does not more than forwarding all 
>>SAX events. A subclass AbstractBufferTransformer could do 
>>most of the work AbstractSAXTransformer and 
>>AbstractDOMTransformer do at the moment. A FilterTransformer 
>>could do the filtering. And so on.
>>
>>There are at the moment 27 transformers extending 
>>AbstractTransformer instead of AbstractSAXTransformer though 
>>every transformer handles SAX events as input and output. The 
>>class hierarchy shall reflect that IMO.
>>
> 
> Not sure, if this is better than what we have. The main idea
> of the AbstractSAXTransformer is to make the development
> of Transformers easier, so it provides a lot of useful function.
> If you use them (know them), writing a transformer is a piece
> of cake.
> For the name: yes, it is a misleading one, but we shouldn't change
> it just for elegance reasons.
> So, for compatibility, I think we should leave everything as it
> is. If there is really a need we could start a refactoring while
> leaving the old ones untouched. But to be honest, I personally
> don't see a need for it.

Maybe I'm just to refactoring friendly for a public project :-)
But clear names often can replace missing documentation and makes the 
usage often more easy.

Joerg

Mime
View raw message