cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject AbstractSAXTransformer
Date Thu, 06 May 2004 09:57:08 GMT
On 06.05.2004 08:31, Carsten Ziegeler wrote:

> The AbstractSAXTransformer is already able to buffer sax events
> in a SAXBuffer. It has several startRecording()/endRecording()
> methods (SAXBuffer, String, DOM etc.)

Uh, didn't know that. But from what I can see (CVS history, javadocs) 
the not-DOM methods were added after 2.1.4 - that's what I'm using and 
so I could not see the new things. A lame excuse - I also did not see 
that it can buffer at all ;-)

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

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.

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.

WDYT?

Joerg

Mime
View raw message