Working out the Internet Explorer Bugs
by Jason S. Kerchner on May 09, 2009 (filed in Development)
I code on a Mac and test in Firefox during the majority of the development process. I do have a PC, sitting in the corner of my office, which I use to test code periodically to make sure everything also works in IE. (I also test Safari, Opera, Chrome and, if I’m feeling generous, Netscape) The great thing about test-driven development is that, since testing is automatic, it’s really easy to test on multiple systems. Just fire up the browser, point it to the test page, and the results are spit out for you.
But, alas, I don’t always do it. Like when I posted the code for my first stab at creating the MVC View. Turns out, there was a problem running the code on Internet Explorer.
The problem was with generating the unique id for the View when one was not given in the constructor. The initContainer function would generate a unique id for you using the getTime function, like so:
1 2 | if (!elem) elem = 'view' + (new Date()).getTime(); |
If elem was not passed in, or was passed in as null, then this would create a new date object and get the time. new Date() should return a new date object with the current date and time, since we are not passing in any arguments. The getTime function returns the number of milliseconds since January 1, 1970. Theoretically, then, each call to getTime should return a new number, since we will not be creating Views within one millisecond of each other. And this works just fine on all browsers except Internet Explorer. Seems IE always returns the same value for getTime. That is unless you get the value, then display it in an alert box. In that case it does function properly. But that’s not a very user-friendly solution.
So, I came up with a solution that uses a static class variable. After creating the LivingMachines.View class, I added a static variable called nextId (line 5).
1 2 3 4 5 | LivingMachines.View = LivingMachines.Class({ /* Lots of code excluded for brevity */ }); LivingMachines.View.nextId = 0; |
I then use this static variable to create the unique id’s for my Views in initContainer.
1 2 | if (!elem) elem = 'view' + LivingMachines.View.nextId++; |
This creates the View id by using the value of nextId, then incrementing that value by 1 so that it’s ready for the next View to be created (hence the name nextId and not currentId).
So, there you have it, static class variables and a fix for IE. And now I know to avoid getTime in IE.
I am currently working on expanding the View’s functionality, and now I have to go fix another IE problem that has cropped up with some of the new code that I am writing. Actually, since it’s after 1 am here, I probably need to go to bed.
May 14th, 2009 on 9:07 am
You can do this in a more broad sense like this.
var uID = 0;
function getUniqueID(){
return ‘g’ + uID++;
}
then call this wherever you want…
foo.id = getUniqueID();
bar.id = ‘prefix_’ + getUniqueID();
May 14th, 2009 on 10:07 am
That’s a good point. I was only thinking of a unique ID for the View, but your approach allows for unique ID’s across the entire application. And I wouldn’t have to code any additional counters when I did need an ID for another purpose. Nice.