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 cziege...@apache.org
