cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <a...@gmx.at>
Subject Re: [RT] C3: Cleaning up SAX module
Date Fri, 30 Jan 2009 08:40:16 GMT
First of all thank you very much for your detailed answer. I can rate most 
ideas from an architectural point of view but what I'm really missing is a 
year long hands on experience. I'm experiment very much with cocoon but 
there's still so much to learn... So, thank you :)

On Thursday 29 January 2009 22:18:29 Carsten Ziegeler wrote:
> Andreas Pieber wrote:
> > I really like the idea of having a common base architecture between all
> > components (sax, stax, ...). I'm not sure if we really have to hold them
> > in sync since its more a basic architectural decision to rely on an a
> > special Producer/Consumer interface than a syncing task. But I just
> > wanted to point out that we sacrifice this basic architecture (existing
> > at the moment) if we remove XConsumer/XProducer. I doesn't want to say
> > that we should not do it, if there are more advantages than drawbacks :)
>
> Ok, usually I'm for a unified architecture if it's possible. But in this
> case I think it doesn't give any advantage. The xml handling differs a
> lot between dom, sax and stax. So even if you find interface with
> similar names (xyzProducer, xyzConsumer) they are completly different
> and have to be used differently when it comes to implementing own
> components.

Yep, but you still know where to start, even if you have no exact idea of dom, 
sax, stax, imaging, ...

>
> Years ago we decided in Cocoon to introduce the XMLConsumer interfaces.
> During the years, it rather proofed that this interface creates
> unnecessary trouble. For example you get some third party stuff
> implementing just content handler, you have to wrap it first. Or if you
> want to write general sax components that work with and without Cocoon,
> you have a dependency on Cocoon just for this interface.
> In the last years I followed the approach the jaxp api follows: just use
> content handler, and check if the object also implements content
> handler. This really simplifies the impl and the handling, makes
> integrating other stuff easy and doesn't create unnecessary dependencies.

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). 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.

An other option would be to let XProducer and XConsumer (maybe renaming them 
to SAXProducer and SAXConsumer :) ) 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? 

Andreas

>
> > I'm very sorry for that but the last days in January are always very
> > painful for Austrian students...
>
> No problem :) we're now having this discussion here and that's all that
> counts.
>
> Carsten


Mime
View raw message