[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xalan-c-users
Subject:    Re: XercesDocumentWrapper not updated when a change  is made in DOMDocument
From:       david_n_bertoni () us ! ibm ! com
Date:       2003-10-03 0:09:45
[Download RAW message or body]





> When I add one node i the DOMDocument that is used to initialize
> XercesDocumentWrapper and then tries to use the xpath functions in the
wrapper,
> to call for the new node my program crashes.
> code for adding node:
>        DOMElement* nyttElement;
>
>        nyttElement =
dokumentM->createElement(XMLString::transcode(element.
>      c_str()));

This call to XMLString::transcode() is leaking memory.

>        DOMNode* nyNod;
>
>        nyNod = nyNod2->appendChild(nyttElement->cloneNode(true));
>

>   // wrapperM is my XercesDocumentWrapper
>   XalanNode* kontextNod = wrapperM->getDocumentElement();
>   XalanNode* xalNod= evaluerare.selectSingleNode(domsupport, kontextNod,
>     XalanDOMString(xPath.c_str()).c_str()); // xPath is a string with my
xPath
>     value
>   return (DOMNode*)(wrapperM->mapNode(xalNod));
>
> I think this happens because the wrapper not is updated when i make
changes in
> the DOMDocument.
> To solve this problem use the rebuild function:
>
>   wrapperM->rebuildWrapper();

Yes, the documentation is explicit about this.  You must rebuild the
wrapper whenever the underlying document changes.

> But whit this solution I need to rebuild the hole wrapper document, witch
could
> be a problem for me when i am using large xml documents.
>

Using large documents with the wrapper is already inefficient.  Are you
sure rebuilding the wrapper is such a big performance problem?

> Is there any functionality where the wrapper is atuomatically updated?
>
> The next best would be a solution where I just have to rebuild the parts
that I
> have made changes in.

There is no functionality to do this, but if you want to write it, it might
be possible to work the changes into the repository.  However, the wrapper
is currently written to be as efficient as possible, so that assumption is
the wrapper is completely rebuilt.  We might lose some efficiency if we
allow a partial rebuild, but there are ways to minimize that loss.

The bottom line is, for now, you'll have to rebuild the entire wrapper.

Dave

[prev in list] [next in list] [prev in thread] [next in thread]