It needs to work such that the same piece of JavaScript can be utilised without modification for any decision tree tool we build on the site, with a very simply-defined markup structure,

So I’ve been self-administering repeated doses of headdesk/facepalm over the last couple of days, but I came back today after a Friday lunch (you know what I mean) and found a solution. It’s not pretty, with at least two nested ‘for’ loops, but it works.

I’ve created a JSFiddle of it, so you can take a look at it, modify it, laugh at it, etc.
Open it in JSFiddle or see it embedded below:

A good friend of mine has, over the years, written a few applications that require graphing. He has written them as VB applications and when I’ve suggested he make them as web-apps, one of his fairly valid objections is that it would be tricky to create good-looking graphs with dynamic data.

Google’s Charting API

So just this morning, the Barnacle drew my attention to Google’s new Charting API (Read the Developers’ Guide). It takes some query string parameters and returns your chart as an image.

Check it out:

Now that’s pretty cool, isn’t it?
Although I think the data encoding, while clever, seems a little quirky.

Flot for jQuery

And so having spotted that this morning, I’m stumbling around the net this evening and discover Flot, a charting plug-in for jQuery. This is teh awesome; just check out the examples, especially the zoom!

So, while you’re waiting for other browsers to support SVG, here’s a veritable choice of quality charting goodness to satisfy the most particular of needs.

Problem

I’ve got an AJAX request to a JSP page which in turn performs an XSL transform on an XML file and returns a bunch of HTML <option> elements that JavaScript inserts into an existing <select> element using innerHTML.

Firefox does it fine, as you’d expect, but IE wasn’t playing nice. The resultant markup was broken, with a missing first opening <option> tag, and some random empty <option> element on the end.

In short, nothing showed up.

Solution

So I turned to google and found: BUG: Internet Explorer Fails to Set the innerHTML Property of the Select Object.

Thanks Microsoft, you just make it so easy. Not even.

I think the best solution here is to do it properly, and change my JSP to return a JSON object or something, and use createElement instead. I know innerHTML is faster, but it’s kinda not proper.

I had a drop-down list of countries, and I wanted users to be able to select more than one country, so had a ‘Add another country’ button that created a new drop-down; copying into it the <option> elements from the first drop-down.

I did the old

var someVar = firstSelect.getElementsByTagName('option');

and then ran a for loop that wrote (using appendChild) all the objects in someVar to a new <select> element. I thought this should be sweet.

But no. It seemed that random option elements were disappearing from the initial <select> element, such that after you’d added a few extra country drop-downs, there were no <option> elements left in the first drop-down to copy from!

As it turns out, someVar actually contains the original option elements themselves, and so I was moving them, instead of copying them.

cloneNode

So, after a bit of googling, I discovered cloneNode.

Using

var justATempVar = someVar[i].cloneNode(true);

in my loop; then writing justATempVar to the new <select> element worked a treat; the original <select> <option>s were left unmolested, and I got my new nodes.

In hindsight, I should have just cloned the <select> node and renamed it, which I will probably do when I get in to work tomorrow. I’m not sure which method is more resource-hungry, but I’m guessing it’s the loop.

I’m not sure whether I’m supposed to be using cloneNode or not, but it seems to work in the versions of IE and Firefox that I’m developing in. Proper testing is yet to see if it works in all our supported browsers.

FYI: The boolean parameter that cloneNode accepts tells the method whether or not to clone child nodes also. This is where I found out about cloneNode.

Thanks, Stuart.

So when the user activates a control, I use JS to create some ‘input’ elements (including some radio buttons), add a few attributes to them, and then insert them in a table cell.
It’s not exactly rocket science, even for a JS |\|00|3 such as myself.

Let me expand on this.

I build in Firefox and test in IE. So I use the following code:

// NB: bits and pieces have been left out for the sake of this example.

// create the cell
var newCell = newRow.insertCell(2);

// create the elements
var newInput1 = document.createElement('input' );		
var newInput2 = document.createElement('input' );
var newLabel1 = document.createElement('label');
var newLabel2 = document.createElement('label');

// set some attributes on those elements
newInput1.setAttribute('type', 'radio');
newInput1.setAttribute('name', 'rdoAddRemove_' + rowIndex);		
newInput1.setAttribute('id', 'rdoAdd_' + rowIndex);
newInput1.setAttribute('value', 'Add');
newInput2.setAttribute('type', 'radio');
newInput2.setAttribute('name', 'rdoAddRemove_' + rowIndex);		
newInput2.setAttribute('id', 'rdoRemove_' + rowIndex);
newInput2.setAttribute('value', 'Remove');
newLabel1.setAttribute('for', 'rdoAdd_' + rowIndex);
newLabel2.setAttribute('for', 'rdoRemove_' + rowIndex);

// append the elements to the cell
newCell.appendChild(newInput1);
newCell.appendChild(newLabel1);
newCell.appendChild(newInput2);
newCell.appendChild(newLabel2);

So you can see what I’m trying to do here, and so could Firefox, because it built the code correctly.

IE, on the other hand, displayed the radio buttons, but wouldn’t allow the user to select them. After much hair-pulling and fretting, (because I can’t find a Firebug equivalent for IE), I discovered that IE wasn’t adding the ‘name’ attributes to the ‘input’ elements.

Apparently (and I’ve lost the link now) IE has a ‘feature’ that means you can’t change the name of an element once it has been created.

So I tried this:

newInput = document.createElement('<input name="rdoAddRemove_' + rowIndex + '" />' );

Yay! It now works in IE! …but the good browsers spat the dummy. And I really felt that if I were going to do this then I might as well ‘innerHTML’ everything.

So I remembered my good old friend try {...} catch(err) {...} and came up with this:

try {
	// IE will eat this, FF Safari and others will choke on it.
	newInput1 = document.createElement('<input name="rdoAddRemove_' + rowIndex + '" />');
	newInput2 = document.createElement('<input name="rdoAddRemove_' + rowIndex + '" />');
} catch(err) {
	// Good browsers will eat this instead.
	newInput1 = document.createElement('input');		
	newInput2 = document.createElement('input');
}

Now whether this is the best way to do it or not, I don’t know, but it worked in all the browsers I tested it in so I’m happy(-ish).

GRRRRR @ IE for wasting my afternoon!!