Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <dev@cocoon.apache.org>
Subject: RE: AbstractSAXTransformer
Date: Sat, 8 May 2004 18:16:01 +0200
Organization: S&N AG
MIME-Version: 1.0
In-Reply-To: <409CFA23.5090501@gmx.de>
Thread-Index: AcQ1Do+02LWwVEcqRMKgBvNfY8ZRCAACRcvw
Message-ID: <OF27A183FD.43D38373-ONC1256E8E.005868FA@sundn.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

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:joerg.heinicke@gmx.de] 
> Sent: Saturday, May 08, 2004 5:18 PM
> To: dev@cocoon.apache.org
> 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
> 
>