David/Colin,
If the decision is not to build a new wrapper (and I can understand why not), then, as I see it, this is not a bug. But it does mean that we can no longer auto-build Xerces trees as output. (The deprecated DOM_Node bridge should still work however.)
The code is quite correctly doing the map to DOMDocument, seeing the result tree is actually based on DOM_Document and is therefore returning NULL.
Colin - I think what you want to do is use the createDocument call to have a target that automatically builds the DOMNode style structure? If that's the case then the new imutable wrapper cannot support this as I understand things.
The createDocument call creates a XalanDocument using a bridge to an old DOM_Document node type. This can then be modified using the mutable wrapper for the old node types by the Formatter.
Creating a similar call for the new wrapper classes will not work as the transformer will throw an exception as soon as it attempts to build the result tree.
If you use a call to mapXercesDocument (rather than mapToXercesDocument) you should be returned a DOM_Document type given the code snippet below. Don't know if this is quite what you want tho?
Your other option (if you have to have a Xerces document at the end) might be to output to a stream and then use Xerces to re-parse the stream?
Cheers, Berin
David N Bertoni/Cambridge/IBM wrote:
Hi Berin,
That's correct, and I just don't want to go there with the new wrapper. Eventually, the old bridge will disappear, and we won't need createDocument() and createDOMFactory() any longer. If we do that, then we can get out of the business of create Xerces documents, which would be a good thing. We also be out of the business of maintaining a complex, hard-to-maintain mutable wrapper around the Xerces DOM.
However, for the time being, we should figure out if the reported problem is a bug, and if so, how to fix it. Do you want to take a look? If not, let me know, and I'll do it.
Dave
|---------+---------------------------> | | Berin Lautenbach| | | <[EMAIL PROTECTED]| | | om.au> | | | | | | 02/01/2003 03:02| | | AM | |---------+---------------------------> >--------------------------------------------------------------------------------------------------------------------------------| | | | To: [email protected] | | cc: (bcc: David N Bertoni/Cambridge/IBM) | | Subject: Re: XercesParserLiaison::mapToXercesDocument is not working (?) | >--------------------------------------------------------------------------------------------------------------------------------|
David,
I had a quick look. Assuming a new createDOMDocument method was created which created a XalanDocument based on a DOMDocument (rather than DOM_Document which is what the current method calls) - I think there is still a problem in that the FormatterToDOM calls appendChild - which in the wrapper classes will throw a NO_MODIFICATION_ALLOWED_ERR exception.
My reading is that fixing this will require the Wrapper classes be updated to allow modification?
Cheers, Berin
Colin Paul Adams wrote:
writes:"David" == David N Bertoni/Cambridge/IBM <[EMAIL PROTECTED]>
XMLString::transcode ( element->getNodeName().c_str() ) << std::endl;
David> Could you also include a small code snippet, so we can David> reproduce it?
I don't know about ALSO - I see there is no selection for reporting bugs against the CVS code.
Here is my snippet (source and sheet are pointers to XSLTInputSources):
XercesParserLiaison the_parser_liaison; XalanDocument * document_result = the_parser_liaison.createDocument(); XSLTResultTarget target ( document_result );
int result = xalan.transform ( *source, *sheet, target );
XalanElement * element = document_result->getDocumentElement();
std::cerr << "Document element is " << element << ", " <<
the_parser_liaison.mapToXercesDocument( document_result );The above code outputs the document element's node name correctly, as generated by the transform.
const DOMDocument * dom_result =
dom_result now has the value 0;
