Yes, deprecating seems to be a good idea. I think we should think of refactoring this (and other parts of Cocoon as well) for the next minor release (2.2).
Carsten > -----Original Message----- > From: Joerg Heinicke [mailto:[EMAIL PROTECTED] > Sent: Saturday, May 08, 2004 5:18 PM > To: [EMAIL PROTECTED] > Subject: Re: AbstractSAXTransformer > > 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 > >
