OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: AW: [sdo] 2nd try: SDOSource, SDOResult and ContentHandler


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):
  • SDOSource createSource(DataObject dataObject, String rootElementURI, String rootElementName);
  • SDOSource createSource(XMLDocument xmlDocument, Object options);
  • SDOResult createResult();

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:
  • Add an accessor to get the XMLHelper used to create the SDOSource
  • Add an accessor to get the XMLDocument (the DataObject/String/String input can be represented as an XMLDocument)
  • Add an accessor to get the options parameter
Then the following could be done:

    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:
  • Add a getContentHandler(): SDOContentHandler method.
    public void save(XMLDocument xmlDocument, Result outputResult, Object options) {
       if(outputResult instanceof SDOResult) {
          SDOResult sdoResult = (SDOResult) outputResult;
          SDOContentHandler sdoContentHandler = sdoResult.getContentHandler();
          save(xmlDocument, new SAXResult(sdoContentHandler), options);
       }
    }

-Blaise

Michael Glavassevich wrote:
OF90D3FE93.D191612D-ON85257581.00653383-85257581.0066D232@ca.ibm.com" type="cite">

Hi Stefan,

"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.org

package 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();
    
}


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]