Andre's Blog

Personal blog of Andre Perusse

Firefox, Internet Explorer, and JavaScript - Good Grief!

For most of my professional career, I've been developing corporate intranet applications. This means I've been pretty lucky as a web application developer when it comes to cross-browser and cross-platform compatibility because most users at the corporations I have worked for use Internet Explorer on Windows. And indeed, my current project has the same kind of user base, but I have taken it upon myself to at least make my application cross-browser so that it works in both Internet Explorer AND Firefox.

It is now that I would like to line up the developers of Internet Explorer AND Firefox and shoot them all. Just bring back Netscape 0.9 beta (the browser I started developing with) and be done with it. The typical zealot out there will tell me that Firefox is standards-compliant and that IE is the source of all evil, and thus the source of all my woes. That may be true. I don't care. This cross-browser compatibility thing is waaaaaay harder than it should be.

On the one hand, we have the usual CSS compatibility issues. No problem - these are well documented and IE hacks abound to get around this stuff. My beef is with simple JavaScript properties and methods. Holy crap. What a mess. I'm sure this is all IE's fault again, so don't feel like you're going to enlighten me on that one either. But really, would the world end if the Firefox developers implemented the "parentElement" property? Or how about the pixelWidth property? Why the hell do I have to use document.getElementById() to get a reference to anything?!? And what the hell is up with Firefox treating whitespace as a freakin' DOM element?!? I could live with everything else, but the whitespace thing has me absolutely fuming. Using the "nextSibling" property or "firstChild" property is just about frickin' useless now - I have to wrap all these kinds of properties in silly helper functions that walk over the DOM elements looking for one that isn't whitespace! Throw me a frickin' bone here, people!

So, for those of you who follow in my footsteps, here are today's hard-learned lessons:

1. Use "parentNode" not "parentElement" when walking up the DOM.

2. Instead of using "nextSibling", wrap it in a function that does this:
   function getNextSibling(previousElement) {
       var nextElement = previousElement.nextSibling;
       while(nextElement.nodeType != 1){
           nextElement = nextElement.nextSibling;
       }
       return nextElement;
   }

3. There is no Firefox equivalent of pixelWidth (if your element has a display style setting of "none"). You have to display the element before you can use offsetWidth which will give you the width of the element in pixels without the stinking "px" added to the end of it.

All this from one page - the application home page. I'm just getting started - I think I'll just sit in the corner and cry now.

 

Computer Keyboards - Deserving More Than Just A Passing Thought

As some of you are already aware, I'm a bit of a gadget freak or "toy boy." One of the things that I'm always keeping my eye on is computer keyboards. How boring, you're probably saying to yourself, but think about it. In the course of a day, how many words do you type? How many keys do you press? If you're a technology worker, the keyboard (and mouse and monitor - but I'll save those for another day) is what you work with ALL DAY LONG. Perhaps we should pay a little more attention to the options we have for making it more comfortable to type.

One of the keyboards I've been looking at is Microsoft's Natural Ergonomic Keyboard 4000 (http://www.microsoft.com/hardware/mouseandkeyboard/productdetails.aspx?pid=043). It's currently $80 at FutureShop and I'm waiting for it to go on sale (the only thing I like more than a tech gagdget is a tech gadget that's on sale!). Also, ExtremeTech just posted a review for the Eclipse II keyboard (http://www.extremetech.com/article2/0,1697,2001569,00.asp) that has an innovative backlight. And if you really want the coolest keyboard ever, take a look at the Optimus (http://www.artlebedev.com/portfolio/optimus/) which uses colour OLEDs to render the characters on the keyboard keys so you can configure the keyboard layout any way you like! Hopefully, one day it will even ship!

Still, my ultimate dream keyboard has yet to be invented. For some reason I haven't yet been able to determine, keyboard manufacturers still insist on putting the numeric keypad on the right side of the keyboard. This means that I have to move my hand a relatively large distance when I have to use the mouse. Keyboard-to-mouse and mouse-to-keyboard movements of your right hand (leftys have the advantage here, methinks) are frequent throughout the computing day and are a major source of user-input disruption. No wonder many software systems require a user-interfaces that can be controlled solely with the keyboard - transferring to "mouse mode" just takes too much time. I think that time could be greatly reduce by moving the mouse closed to the main keyboard keys, but what do I know?

Visual Studio 2005, Auto-Generated DataSets, and Computed Columns

So, as a developer who prefers to roll his own code for data access layers (i.e., build my object model in a Business layer (BLL), write data methods in a data layer (DAL), write stored procedures, etc. with copious use of CodeSmith), I decided to give Typed Datasets a try in one of my recent projects. I was hoping to achieve a huge productivity boost in not having to write any BLL or DAL code. The app was small, not really high-traffic, so I didn't mind giving up all the control I would have had with my usual method.

Well, lo-and-behold it worked quite well! I was able to assemble the app rather quickly and I could concentrate most of my efforts on the actual application as opposed to the data plumbing. Just drag and drop all the tables onto a DataSet designer, add a few queries here and there, and I was done! So impressed was I by this, I decided to use it again in another project.

In doing so, I was reminded why I prefer to roll my own code all the time. I'm using SQL Server 2000, and one of my columns in one of my tables is a computed column. Drag and drop tables onto the DataSet designer, add some queries, everything is going fine so far. Then I try to update a record in my web app. Ka-boom! I get this error message:

Column 'overallValue' cannot be modified because it is a computed column.

I know immediately what this is: the DataSet designer doesn't check the schema for computed columns when dragging and dropping tables onto the designer surface. Thus, its auto-generated INSERT and UPDATE statements include the computed columns. Arg!!!

So, not a big deal really, I dive into the auto-generated code and fix up the INSERT and UPDATE statements for this TableAdapter. Of course, if I ever have to re-gererate the DataTable (due to a schema change, for example), I have to remember to perform this little hack. Grrrr......

While I'm not going to abandon VS 2005's auto-generated Typed Datasets feature (even with this problem, it's still far too productive to just chuck it), this kind of problem is just so typical of auto-generated stuff - it nevers takes into account everything. If you're lucky (like I was this time), you'll be able to figure out what's wrong and fix it up with a little hacking in a short time. However, the more complex they make the auto-generated stuff, the more difficult it becomes to do this.