Re: [RT] C3: Cleaning up SAX module

[Carsten Ziegeler <cz...@apache.org>]

Andreas Pieber wrote:
> 
> I'm not convinced that removing XProducer and XConsumer will resolve all 
> problems described by you since you still need a reference to Cocoon (e.g. for 
> PipelineComponent and Producer/Consumer). 
Yes, you got me :)

> One possibility to get rid of all 
> references could be the spring framework. POJOs with a ContentHandler and an 
> setConsumer(Object) method could be (very easily) described in XML and wrapped 
> at runtime to "real" PipelineComponents.
Yes, but if I really want to do this, I can do this regardless if we
have SAXConsumer (XMLConsumer) or not.

> 
> An other option would be to let XProducer and XConsumer (maybe renaming them 
> to SAXProducer and SAXConsumer :) ) 
(Yes, we should rename them and I think we already agreed on this on)

> and just weaken the conditions. The 
> components simply check for an ContentHandler/LexicalHandler as they require. 
> With this approach you let the decision to the developer if he like to simply 
> inherit from the X-Interfaces and has an SAXPipelineComponent, a 
> ContentHandler and so on at once or do it on his own. WDYT about this 
> approach? 
Hmm, not sure :) Seems like a wrong compromise to me :) Either we really
want these interfaces for symmetrical reasons (which I think is not
worth doing it and given the different between the formats itself
doesn't help) or if we want the simplest approach for each type (xml,
dom, stax). I would vote for the second approach.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] C3: Cleaning up SAX module

[Andreas Pieber <an...@gmx.at>]

On Monday 02 February 2009 17:51:25 Carsten Ziegeler wrote:
> > and just weaken the conditions. The
> > components simply check for an ContentHandler/LexicalHandler as they
> > require. With this approach you let the decision to the developer if he
> > like to simply inherit from the X-Interfaces and has an
> > SAXPipelineComponent, a ContentHandler and so on at once or do it on his
> > own. WDYT about this approach?
>
> Hmm, not sure :) Seems like a wrong compromise to me :) Either we really
> want these interfaces for symmetrical reasons (which I think is not
> worth doing it and given the different between the formats itself
> doesn't help) or if we want the simplest approach for each type (xml,
> dom, stax). I would vote for the second approach.

I'm still the opinion that it may help newcomers to jump into cocoon if they 
find a common interface-structure between all components. But on the other 
hand a newcomer would work with the AbstractTransformers (mostly) and not 
directly with COMPONENT-Producer/COMPONENT-Consumer...

Finally all my counter arguments for removing SAXC/SAXP are said and 
discussed. I still like them but I've no problems with removing them :) . If 
nobody else has any problems with it we could continue at 
https://issues.apache.org/jira/browse/COCOON3-22

Thank you Carsten for taking the time to discuss this topic with me.

Andreas