Re: [RT] C3: Cleaning up SAX module
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
Re: [RT] C3: Cleaning up SAX module
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
Re: [RT] C3: Cleaning up SAX module
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
Re: [RT] C3: Cleaning up SAX module
SEE https://issues.apache.org/jira/browse/COCOON3-22 Carsten Ziegeler commented on COCOON3-22: - Ok, having worked with the xml consumer interface for years now, I came to the conclusion that things get much simpler if you just rely on content handler It makes using the sax stuff much easier and more convenient - I don't think that we need to keep the stax stuff and other impl in sync just for the sake of having them in sync. 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 :) But please let's do this discussion in the mailing list - i've started an RT some days ago about this topic and so far got only positive response (from Sylvain) I'm very sorry for that but the last days in January are always very painful for Austrian students... On Tuesday 27 January 2009 08:32:14 Carsten Ziegeler wrote: Hi, I think we can reduce the number of interfaces in the SAX module by just removing XMLProducer and XMLConsumer. XMLProducer is just a marker interface combining Producer and SAXPipelineComponent, so we can just remove it. XMLConsumer combines LexicalHandler, ContentHandler and Consumer. I think we can remove this and just rely on ContentHandler for chaining sax components. When sax components are chained, they can simply check if the next component implements LexicalHandler as well or not. With this simple improvement we can also remove the XMLConsumerAdapter. WDYT? Carsten
Re: [RT] C3: Cleaning up SAX module
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. 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 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 -- Carsten Ziegeler cziege...@apache.org
Re: [RT] C3: Cleaning up SAX module
Carsten Ziegeler wrote: Hi, I think we can reduce the number of interfaces in the SAX module by just removing XMLProducer and XMLConsumer. XMLProducer is just a marker interface combining Producer and SAXPipelineComponent, so we can just remove it. XMLConsumer combines LexicalHandler, ContentHandler and Consumer. I think we can remove this and just rely on ContentHandler for chaining sax components. When sax components are chained, they can simply check if the next component implements LexicalHandler as well or not. With this simple improvement we can also remove the XMLConsumerAdapter. WDYT? Yup, it's easier to wrap separate ContentHander and LexicalHandler objects into a simple wrapper implementing both interfaces rather than having to deal with a Cocoon-specific XMLConsumer everywhere. Now we should also consider javax.xml.sax.SAXResult that holds a ContentHandler and an optional LexicalHandler, and has an interesting SystemId property that could be used to propagate a base URI from one component to the next one without relying on an external resolver context. And the fact that SAXResult _holds_ the handlers rather than implementing the interfaces can in many cases avoid a level of wrapping as the one mentioned above. But the properties in SAXResult are mutable and the javadocs don't specify when these properties can change, i.e. if a producer should call getHandler() every time it needs to produce events of if the value can be kept for the whole stream of events, even if I think the second case is the most often used. So in the end, using a ContentHandler that optionally implements LexicalHandler looks like the simplest and most robust solution. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] C3: Cleaning up SAX module
Sylvain Wallez wrote: Now we should also consider javax.xml.sax.SAXResult that holds a ContentHandler and an optional LexicalHandler, and has an interesting SystemId property that could be used to propagate a base URI from one component to the next one without relying on an external resolver context. Ah interesting idea. And the fact that SAXResult _holds_ the handlers rather than implementing the interfaces can in many cases avoid a level of wrapping as the one mentioned above. Yepp But the properties in SAXResult are mutable and the javadocs don't specify when these properties can change, i.e. if a producer should call getHandler() every time it needs to produce events of if the value can be kept for the whole stream of events, even if I think the second case is the most often used. Ah too bad :( So in the end, using a ContentHandler that optionally implements LexicalHandler looks like the simplest and most robust solution. Yes, it seems better than relying on a not clearly specified assumption (btw, if the sax result just has a content handler, this should be tried to be casted to a lexical handler as well, so we are in good company) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [RT] C3: Cleaning up SAX module
Carsten Ziegeler wrote: Sylvain Wallez wrote: So in the end, using a ContentHandler that optionally implements LexicalHandler looks like the simplest and most robust solution. Yes, it seems better than relying on a not clearly specified assumption Absolutely! (btw, if the sax result just has a content handler, this should be tried to be casted to a lexical handler as well, so we are in good company) Indeed ;-) Sylvain -- Sylvain Wallez - http://bluxte.net
[RT] C3: Cleaning up SAX module
Hi, I think we can reduce the number of interfaces in the SAX module by just removing XMLProducer and XMLConsumer. XMLProducer is just a marker interface combining Producer and SAXPipelineComponent, so we can just remove it. XMLConsumer combines LexicalHandler, ContentHandler and Consumer. I think we can remove this and just rely on ContentHandler for chaining sax components. When sax components are chained, they can simply check if the next component implements LexicalHandler as well or not. With this simple improvement we can also remove the XMLConsumerAdapter. WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org