Home & blog  /  2011  /  Nov  /

Additions to XML tree; jQuery XML parsing

posted: 24 Nov '11 08:45 tags: XML, tree, traversal, node, parsing

You may have seen my XMLTree plugin, posted a few weeks ago.

If you'll excuse the trumpet-blowing I do find this plugin among my most useful; I'm working on a number of projects right now that involve XML in the browser, and the ability to visualise it in a traversable tree is quiet satisfying.

New features (all documented on the script page) include:

- callback on resultant HTML - you can now specify a callback function which will be invoked after the tree has been generated. It is automatically passed a DOM reference to the tree ul so you can act on it.

- attributes - can now be ignored, hidden or shown. Hiding them is useful if you plan to traverse or interrogate the tree based on their existence or value, without wanting to show them to the user.

Bug fixes

This was an interesting one. With XMLTree you can either point it at an XML file for it to load, or manually pass it a well-formed string of XML.

In the latter case, it exploits a well-known (yet somewhat abused) perk of jQuery - that you can pass it a DOM or XML string and it will turn it into a nodeset.

But because this is intended for DOM creation, not XML creation, it assumes you're parsing an HTML document, not XML. The problem? If your XML contains any tags that share their names with any self-closing HTML tags, jQuery renders your XML invalid.

Consider the following example:

1var xml = "http://mitya.co.uklink>";

2console.log($(xml).html());

The output of that will be:

/>http://mitya.co.uk

...which is obviously not what you'd wanted.

As a fix for this XMLTree now renames (secretly) all of the node names - but restores their original names on output.

Ideally, of course, I wouldn't be lazy and rely on jQuery to parse XML - there are native ways (albeit different ones for different browsers). But for now this fix works just fine.

Head over here to download, get usage info or view a demo.

post a comment

BAPS (browser and plugin sniffer)

posted: 13 Nov '11 17:34 tags: browser, sniffer, detection, navigator, plugin, OS

BAPS, apart from being an acronym chosen purely for its its puerile humour, stands for browser and plugin sniffer - and I've just posted it in the scripts section.

As promised earlier this week, this is a utility to accurately detect information about the user's environment, such as browser name, version, language and installed plugins.

This is an area that is famously annoying, since different browsers expose different information to the Javascript's native navigator object, which exists to tell developers about the user's environment. Thus, it's never been standardised.

BAPS clears this up, as it caters for browsers' inconsistencies. It caters, for example, with the fact that Opera 11.52 declares itself as Opera 9.8. And for the fact that Chrome declares itself as, er, Netscape.

It sets a global variable, baps, which is an object containing various information about the user's environment, such as browser, version, language and plugins.

In terms of plugins, it detects Flash, WMP and QuickTime, but you can easily extend it to look for more.

Head over here to download, get usage info or view a demo.

post a comment

Roundup: animated table sort / browser sniffing

posted: 07 Nov '11 07:04 tags: table, sort, animation, browser, sniff, plugin, navigator

With the exception of Blockster, the most popular script I've ever posted is my animated table sorter.

Which is rather odd, since as far as I'm aware it's buggy. Somehow, though, if the comments and e-mails are anything to go by, loads of people have been able to use it just fine.

Given this unexpected popularity I'm going to attempt to rebuild it in the coming months.

This script is among the top five hardest scripts I've written, so I'll, er, look forward to that.

In other news, stay tuned for my next script, later this week - a browser and plugin sniffer.

Browser sniffing is one of those things that you can't believe there still isn't a standard way of doing. Even jQuery's $.browser utility comes with a load of caveats warning that results might not be as expected.

And it's little wonder. Different browsers declare different, non-standard data in the various properties of the navigator object. Over the years these have led to some amusing revelations; if you ask Chrome what its navigator.appName is you'll get... Netscape. Naturally.

So I've been labouring away on a script that will provide you with something representing a reliable utility for this sort of thing. Not only with regards to detecting browser name but also other info such as language (more on that later...) and plugin support (and on that...).

post a comment
older posts >