Hi Berin/Colin,
Just to clarify -- we _do_ have a new wrapper, we just don't support
_modifying_ the underlying Xerces DOMDocument instance. through it. I
think that's a reasonable limitation given the complexity of the code in
the old bridge, and the problems it caused. (like users building the
bridge nodes, then modifying the document, and wondering why the new nodes
don't appear, etc.)
However, we _can_ build Xerces DOMDocument instances as the output of a
transformation. In fact, I just checked in a new sample and some support
classes for that very purpose. If you pull down the latest CVS, you'll get
it. It's called TransformToXercesDOM. I haven't checked in changes to
Makefile.in to include it in the build, but I've maded the changes locally
and will check it in very soon. It's already in the Visual C++ workspace.
Dave
|---------+--------------------------->
| | Berin Lautenbach|
| | <[EMAIL PROTECTED]|
| | om.au> |
| | |
| | 02/01/2003 01:48|
| | PM |
|---------+--------------------------->
>--------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [email protected]
|
| cc: (bcc: David N Bertoni/Cambridge/IBM)
|
| Subject: Re: XercesParserLiaison::mapToXercesDocument is not working
(?) |
>--------------------------------------------------------------------------------------------------------------------------------|
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:
>
>
>
>>>>>>>"David" == David N Bertoni/Cambridge/IBM
<[EMAIL PROTECTED]>
>>>>>>>
>>>>>>>
>writes:
>
>
>>>>>>>
>>>>>>>
>> 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 << ", " <<
>>
>>
>XMLString::transcode ( element->getNodeName().c_str() ) << std::endl;
>
>
>>The above code outputs the document element's node name correctly, as
>>generated by the transform.
>>
>> const DOMDocument * dom_result =
>>
>>
>the_parser_liaison.mapToXercesDocument( document_result );
>
>
>>dom_result now has the value 0;
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
