IDOMParser Design / Coding Question

["Cornelius, Martin" <Ma...@softwareag.com>]

Hi all, 

i just stumbled about some coding in the IDOMParser that makes me wonder: In
many places, the objects created by IDOM_Document::createXXX() functions are
downcasted to Implementation Object pointers, silently assuming that
IDOM_DOMImplementation always constructs this special realization. 

e.g.:

void IDOMParser::startElement(const  XMLElementDecl&         elemDecl
                             , const unsigned int            urlId
                             , const XMLCh* const            elemPrefix
                             , const RefVectorOf<XMLAttr>&   attrList
                             , const unsigned int            attrCount
                             , const bool                    isEmpty
                             , const bool                    isRoot)
{
    IDOM_Element     *elem;

    if (fScanner -> getDoNamespaces()) {    //IDOM Level 2, doNamespaces on
        XMLBuffer buf;
        XMLCh* namespaceURI = 0;
        if (urlId != fScanner->getEmptyNamespaceId()) {  //TagName has a
prefix
            fScanner->getURIText(urlId, buf);   //get namespaceURI
            namespaceURI = buf.getRawBuffer();
        }
        elem = fDocument->createElementNS(namespaceURI,
elemDecl.getFullName());

        IDElementImpl *elemImpl = (IDElementImpl *) elem;
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       ........
             elemImpl->setAttributeNode(attr);
       ........
}

 
In this special case, the intermediate pointer and the cast seems not
necccessary at all and is hopefully optimized away. Generally: Why should
the IDOMParser have knowledge about IDOMs implementation internals instead
of just using the IDOM_xxx Interface ?

I'm particularly concerned about this because we are currently building an
extended DOM Implementation derived from IDOM_DOMImplementation. My
intention was to later reuse the IDOMParser by just changing the one line of
code in the parser that gets the Dom Implementation, but this seems to be
impossible with the current coding.

Thanks for any response, Martin.




---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org