cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: AbstractSAXTransformer
Date Fri, 07 May 2004 07:56:43 GMT
Joerg Heinicke wrote:
> 
> 
> Some comments to this beast:
> This transformer looks very complicated - to many stuff in 
> it. I only had a quick look on it, but I could not find how 
> the recording is started. In theory it must be in a content 
> handler method in a subclass that calls start***Recording ??
Yepp, that's the idea. You match for the element you're
interested in, start the recording, match for the corresponding
end element event, end the recording and have your info
in the desired format.

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

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

Carsten


Mime
View raw message