[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [sdo] 2nd try: SDOSource, SDOResult and ContentHandler
Hi Blaise,
Hello Stefan & Michael, I have been re-thinking the decision to make SDOSource and SDOResult abstract classes. In JAXB, JAXBSource and JAXBResult are concrete classes that extend their SAX counterparts. JAXB benefits from not needing a factory, but suffers from exposing meaningless public API, the best they can do is add Java doc comments stating that the users should not consider using the inherited API. If we go the factory route then we can offer the benefit of a clean API, and also the potential for implementors to offer Source/Result implementations better tuned for their implementation (on DOM, SAX, or StAX). All we really need are the attached interfaces and some new creation methods on XMLHelper (the following are based on current XML Helper API):
If there are expectations that a SDOSource from one vendor can act as input to another vendors SDO implementation load operation we can enhance the SDOSource interface further:
public XMLDocument load(Source inputSource, String locationURI, Object options) { if(inputSource instanceof SDOSource) { SDOSource sdoSource = (SDOSource) inputSource; SDOContentHandler sdoContentHandler = this.createContentHandler(options); sdoSource.getXMLHelper().save(sdoSource.getDocument(), new SAXResult(sdoContentHandler), sdoSource.getOptions()); return sdoContentHandler.getDocument(); } } If there are expectations that an SDOResult from one vendor can serve as the output to another vendors SDO implementation save operation we can enhance the SDOResult interface further:
if(outputResult instanceof SDOResult) { SDOResult sdoResult = (SDOResult) outputResult; SDOContentHandler sdoContentHandler = sdoResult.getContentHandler(); save(xmlDocument, new SAXResult(sdoContentHandler), options); } } -Blaise Michael Glavassevich wrote:
"Buennig, Stefan" <stefan.buennig@sap.com> wrote on 03/20/2009 05:50:21 AM: > Hi Michael, > > what do you think about this SDOResult implementation? Looks good. That's roughly what I was thinking of. > package commonj.sdo.helper.util; > > import javax.xml.transform.sax.SAXResult; > > import commonj.sdo.helper.HelperContext; > import commonj.sdo.helper.SDOContentHandler; > import commonj.sdo.helper.XMLDocument; > > public class SDOResult extends SAXResult { > > private XMLDocument document; > > public SDOResult(HelperContext helperContext, Object options) { > SDOContentHandler sdoContentHandler = helperContext. > getXMLHelper().createContentHandler(options); > setHandler(sdoContentHandler); > } > > public void setDocument(XMLDocument document) { > this.document = document; > } > > public XMLDocument getDocument() { > if (document == null) { > SDOContentHandler sdoContentHandler = > (SDOContentHandler)getHandler(); > document = sdoContentHandler.getDocument(); > } > return document; > } > > } > I'm wondering if there should be another constructor to avoid the > initialization of the SdoContentHandler. This could be useful for > users of the setDocument-method. Which use-case do you have in mind > for the setDocument-method? The library/framework writing to the SDOResult might be SDO-aware and use the setDocument() method but I generally wouldn't expect the application creating the SDOResult to know that. If you want to avoid creating the SDOContentHandler in the constructor I suppose you could cache the HelperContext/options and only create the SDOContentHandler if the getHandler() method is invoked. I'm not sure what "options" can be passed in but if they configure the behvaiour of the SDOContentHandler then they should probably be exposed from SDOResult so that a framework which produces SDO directly can match the behaviour of SDOContentHandler or choose to fall back to using the SDOContentHandler if it doesn't understand or support the options. > Would you rather prefer an abstract class? If I were designing SDOSource/SDOResult I probably wouldn't make them abstract but I don't feel strongly either way. > Stefan. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com E-mail: mrglavas@apache.orgpackage commonj.sdo.helper.util; import javax.xml.transform.Source; public interface SDOSource extends Source { } package commonj.sdo.helper.util; import javax.xml.transform.Result; import commonj.sdo.helper.XMLDocument; public interface SDOResult extends Result { XMLDocument getDocument(); } --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]