Discuss: Cross-Browser Scripting with importNode()

by Anthony Holdener

1 Untitled

Why not just use Json, its faster and smaller?

posted at 12:04 pm on March 27, 2007 by Thinkel Man

From my experience over the past years I’ve to say that I won’t go back to XML handling in XmlHttpRequests ever. And, [removed] being standards or not, de facto it works every and it is fast. And speed is a concern, especially if your application gets bigger and bigger.

Same for harvesting through XML data isles. Your browsers native scripting language is JS, so JSON seems just more natural to me for any data exchange.

As long as you don’t have to provide the XML to another place where it is required I don’t see a justification for it.

posted at 12:46 pm on March 27, 2007 by Markus Fischer

3 Untitled

Broken link: «Download the final solution»

posted at 01:49 pm on March 27, 2007 by Vadim Makeev

4 AJAX or AJAJ?

ThinkelMan summed up my first thoughts exactly when reading this article. I have to admit your solution is nice but I can’t help thinking you caused yourself alot of extra work when you could have accomplished much the same thing using JSON rather than XML as the response format.

Was there any particular reason for choosing XML over JSON in the application?

posted at 03:06 pm on March 27, 2007 by Aaron Bassett

5 Workaround for innerHTML instead of importNode()

You could also write some IE innerHTML workarounds, e.g. setting the innerHTML of a <SELECT> box using the IE outerHTML property:

if (node.outerHTML && node.nodeName == “SELECT”) { selectNode.outerHTML = selectNode.outerHtml.replace
(/(<SELECT[^<]*>).*(<\/SELECT>)/, ‘$1’ + content + ‘$2’);
} else { selectNode[removed]=content;
}

posted at 03:37 pm on March 27, 2007 by Christian Köberl

6 Taconite

For full-featured XML processing support check out Taconite (http://sourceforge.net/projects/taconite/) or its jQuery equivalent (http://malsup.com/jquery/taconite). These libs have long since solved the importNode problem in a manner that hides all the details from the user.

posted at 04:27 pm on March 27, 2007 by sup dog

7 Problem due to mixed technique

There are generally two approaches to retrieving data by asynchronous request:

Retrieve an XML (or JSON) object containing data nodes, then parse out that data and build the HTML client-side.

Retrieve raw text or HTML to insert into an element using innerHTML (or whatever).
These two approaches are meant for different uses, but the author of the article seems to want to use both at the same time.

If you want data, parse it out and manipulate it as you like. If you want prebuilt HTML, ask the server for that and don’t try to parse it yourself.

In other words, I think the whole problem can be avoided, insofar as the provided example.

posted at 06:13 pm on March 27, 2007 by Tim McCormack

8 XML or JSON

JSON is a very viable solution if I were taking data, say, from a database and sending that asynchronously to the client from the server. If I want to strip out sections from a page that is already formatted as XHTML, though, why go through the hassle of:

1. converting it to JSON on the server from wherever it came from
2. sending it to the client
3. converting it back to XHTML on the client

XML works well in these cases and has no additional processing costs.

I’m not an XML zealot by any means, but I like to have solutions for every scenario out there just in case it comes up. I understand where Markus and Tim are coming from.

posted at 07:18 pm on March 27, 2007 by Anthony Holdener

9 Seems like a nice, simple solution

I understand what people are saying about importing then parsing XML or alternately using innerHTML, and why some people think this _importNode script is pointless. However, I think this script has potential.

My scenario: I have pre-existing XHTML pages I’d like to grab data from. This eliminates JSON because the data is already in XHTML format. I can import the pages as XML, but then I run into trouble with formatting markup (such as <em>). I can use innerHTML, but that means giving up DOM scripting control over the imported data.

It appears this script will let me import a chunk of XHTML from an existing page, retain existing XHTML markup such as <em> and CSS selectors, and also be able to manipulate it via the DOM. And as a plus, it does it with a very small script that is cross-browser and reusable.

What more can I ask for? :)

posted at 07:52 pm on March 27, 2007 by Philip Hutchison

10 Similar approach

We took a similar approach at my work, where we had a XML response containing a HTML “payload” among other things. We wanted to to inject the HTML into the page without resorting to parsing the responseText with a regular expression and using innerHTML. What we came up with was a copyNodes function:

http://www.stringify.com/misc/copynodes.js

This function allows you to specify a source node in the responseXML, a destination node in the current document, and an optional filter to weed out unwanted nodes.

posted at 08:48 pm on March 27, 2007 by David Lindquist