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
