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

[Michael Glavassevich <mrglavas@ca.ibm.com>]

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