Re: XercesParserLiaison::mapToXercesDocument is not working (?)

Berin Lautenbach 2 Feb 2003 07:34:51 -0000

Ahh!  Much cleaner than my solution :>.

It also means that this _could_ be classed as a bug (in that there is no
way to directly tell a XalanTransformer to output a XercesDOM without
yourself creating a Formatter), but fixing requires the following :

1 Create a new "createDOMDocument" method within XercesParserLiaison
that creates a XalanDocument based on a DOMDocument

2 Have a way within XSLTResultTarget of determining that the
XalanDocument is actually a wrapper for a Xerces DOMDocument and then
extract the DOMDocument to manipulate directly.

3 Modify StylesheetRoot, StylesheetExecutionContext and
StylesheetExecutionContextDefault to handle a FormatterToXercesDOM that
uses the input DOMDocument.

1 and 2 seem very ugly.  You create a wrapper then discard it, and then
you have a problem after doing the formatting of re-mapping the nodes to
make sure anyone manipulating as a XalanDocument is still OK.

Might it be cleaner to create a new constructor and set of methods
within XSLTResultTarget to take a Xerces DOMDocument as the output
definition?  That takes care of 1 and 2 without significantly
complicating things, and seems to be more in the spirit of the
XSLTResultTarget.

Or am I right off the mark :>.

Cheers,
    Berin

David N Bertoni/Cambridge/IBM wrote:

> > >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; >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> > > > > > > >

Re: XercesParserLiaison::mapToXercesDocument is not working (?)

Reply via email to