Copy responseXML DOM fragment to the document

  • Thread starter Alexander Mikhailian
  • Start date
A

Alexander Mikhailian

I have an http = new XMLHttpRequest(); that provides me with an
http.responseXML. Somewhere deep in the http.responseXML there is a fragment
called e.g. mydom that I want to copy with all its children to the document.

document.getElementsByTagName('body')[0].innerHTML=mydom; does not work. What
should I do? Traverse mydom manually? Look for a JS library that does this
already?
 
M

Martin Honnen

Alexander said:
Somewhere deep in the http.responseXML there is a fragment
called e.g. mydom that I want to copy with all its children to the document.

document.getElementsByTagName('body')[0].innerHTML=mydom; does not work. What
should I do?

Well
document.getElementsByTagName('body')[0].innerHTML
suggests you have script in an HTML document so to have any chance to
simply move nodes from that responseXML document to the HTML document
those nodes should be XHTML nodes then.
And the XML DOM and the HTML DOM must be a common DOM which allows to
use importNode to to import nodes from one document to another, like
Mozilla or Opera do.
So with Mozilla and with Opera you could have for instance the XML

<?xml version="1.0" encoding="UTF-8"?>
<data>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Kibology for all.</p>
<p>All for Kibology.</p>
</div>
</data>

and then you could do e.g.

var responseXML = httpRequest.responseXML;
var div;
if (responseXML && typeof responseXML.getElementsByTagNameNS !=
'undefined' && (div =
responseXML.getElementsByTagNameNS('http://www.w3.org/1999/xhtml',
'div')[0])) {
var clonedDiv = document.importNode(div, true);
document.body.appendChild(clonedDiv);

to import that XHTML <div> element and its contents into the HTML document.


But within IE/Win you use the HTML DOM MSHTML implements and the XML DOM
MSXML implements and those are completely separate implementations where
you can't simply move/import nodes from one document to the other. Nor
does MSXML in any way recognize the XHTML namespace and build XHTML
nodes when parsing that XML. Thus with IE you need to either write your
own code traversing the XML DOM and creating HTML nodes as needed or you
need to try to parse the XML as HTML tag soup in IE using innerHTML or
insertAdjacentHTML. So there you could try
htmlElement.innerHTML = xmlNode.xml

Or you could use XSLT first to transform the XML to HTML as a string and
then use innerHTML or insertAjdacentHTML.

So going cross browser gets complicated but libraries are around that
could ease your task, at least initially, until you run into problems as
a library might favour a certain approach or implementation and then
fails to mimic that approach correctly with other implementations.
 
A

Alexander Mikhailian

Martin Honnen said:
So going cross browser gets complicated but libraries are around that
could ease your task, at least initially

Thank you for such a complete explanation of the subject! One question
remains, though: wouldn't it be wiser to ignore the importNode (as a DOM level
2 function) and innerHTML (as a hack) and use a library that copies one DOM to
another (copyDOMs(DOM1, DOM2)?) by walking over the source DOM using just DOM
level 1 functions that are supposedly more or less the same among different
browsers?

Given that DOM traversal is an intricate subject in itself, I wonder if there
a is a stable implementation already.
 
M

Martin Honnen

Alexander Mikhailian wrote:


wouldn't it be wiser to ignore the importNode (as a DOM level
2 function)

Well if you already have HTML nodes and simply need to import them into
another document then with those implementations that support that you
certainly gain stability and performance compared to any attempts to
write that yourself or to serialize first and then reparse.
and innerHTML (as a hack) and use a library that copies one DOM to
another (copyDOMs(DOM1, DOM2)?) by walking over the source DOM using just DOM
level 1 functions that are supposedly more or less the same among different
browsers?

I think the Sarissa library for instance for some time tried to
implement importNode for IE by walking one DOM and creating nodes in the
other DOM but found setting someDiv.innerHTML =
someResponseMarkupAsString to be much faster.

As for DOM Level 1 and sticking with that, I am not sure that helps
much, if you want to process XML with namespaces (XHTML for instance,
Atom feeds, SVG, to name a few) then you need DOM Level 2 stuff to
correctly deal with namespaces (or you need to go XPath as with MSXML in
IE).
And then when it comes to create stuff in an HTML document with the DOM
you can have bad suprises if you try DOM Level 1 Core stuff like
setAttribute where IE has its own legacy implementation for instance not
being compatible with the W3C DOM specification (mainly by not
distinguishing between the attribute in the core DOM and the property in
the HTML DOM).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,534
Members
45,007
Latest member
obedient dusk

Latest Threads

Top