I have to be honest, since version 5 of Internet Explorer I have really not been all that interested in the Netscape/
Mozilla browser. There werefour compelling reasons for me to really consider IE as my preferred tool of choice. The reasons, in order of relevance, were 1)
XmlHttp object support; 2)
XSL support (yes, even if it pre-dated the standard); 3) Embedding; and 4) Always there.
I will leave it to the purists in this world to worry about whether IE implements every standard under the
W3C banner. By having the above mentioned items it was really a no brainer to adopt it for any html based work I may have to tackle.
I can recall reading that direct
XSL support was not something high on the list of priorities for the
Mozilla developers (sorry, cannot recall any useful links) and that
CSS styling plus JavaScript could accomplish all the same bells and whistles (if you didn't mind doing it that way that is).
When IE 5 was originally released I was quite impressed and wanted to toy with the new features. I had an internal project, a bug/ticketing system, that I used for experimenting with the creation of a viable web based application (my preference is still for full rich client applications, so that is the bar with which anything web application will be measured against). In particular, this application makes use of a
Delphi ISAPI library connected to an
Oracle database through a custom OCI connectivity layer built specifically for server processing in
Delphi. The content produced by the library is almost exclusively
XML content with a bit of
HTML for good measure (and laziness). All content is processed on the client workstation using
XML/
XSL transforms and client-side validations via a decent amount of JavaScript code. Throughout the process the intent was to ensure that the minimum number of client-server round trips are used and real"data" is the only moving on the wire (It really does bother me to see 90% of the content of an
HTML page being markup, etc. that has nothing to do with the last POSTed data... seems like a real waste no matter how much bandwidth you can afford). To this end the client-side bits perform all the
XML/
XSL transforms, do a significant amount of validation via JavaScript, locally cache large volumes of data including code tables, client lists, etc. using "userdata" behaviours, and many of the interactions with the server take place using the XmlHttp object. The net effect of the entire project is that after a user visits only a couple of the pages they have virtually everything they need already sitting in the client browser cache or local store. The application then only needs to pass "real" data back and forth between the
ISAPI library and the browser.By the way, this was 1999.
Great, but definitely no support for Netscape at the time and with the fledgling Mozilla there didn't seem to be much hope.This project has basically been left unaltered since being originally constructed.
That brings us to the here and now... A bug in the background e-mail handling code for the
ISAPI library forced me to revisit the code and much to my shock and dismay wasn't it horribly formatted
HTML and
XSL based on the pre-XSL-T provided by Microsoft (with embedded script to make up for the shortcomings). This is where FireFox comes into the picture. As part of assessing the present state of the FireFox browser is whether it is capable of being a client to this browser application that was developed using so much IE specific functionality.
My first step was to get rid of the outdated
XSL transforms and replace those with standards based versions. That was pretty easy and it certainly didn't take long to get most of the content viewing aspects of the web application up and running under the FireFox browser but it looked horrible (recall that I already declared the HTML a mess). Being a self-proclaimed
XML addict I decided the best solution to getting a consistent rendering of the page content was to ensure that I was producing the most well-structured
HTML I could. This lead me to using the
DOCTYPE declarations and converting the content to be
XHTML 1.0 Strict compliant. While it wasn't incredibly difficult I have to say it was painful converting all the tags to lowercase, stripping attributes, creating styles, etc. The net effect of the HTML upgrades was a very consist view from both IE6 andFireFox... I must say doing it today is much easier than it was four years ago.
A pet peev here and a focus for a future entry is the "how" I did the validation seeing as the site is served over SSL on a private network using NTLM for authentication.So, at that point, I was able to view the site under FireFox without having it complain about outdated stylesheets and consistently rendering the content. I still couldn't get the benefits of the search and edit areas of the ticket application. These particular bits rely on having the browser being able to communicate without having to do a "post-back" or any of that horrible typical web application processing (yes, it has it's place but I like to keep it to a minimum, I still just want data moving on the network). I wasn't interested in completely reverting the web application over to use the typical edit-post-refresh cycle so I really needed for FireFox to support XmlHttp. While meandering through the online documentation I saw that they have a good implementation of the
DOM which includes support for the "load()" method as well as a method of constructing an
XML document on the fly within JavaScript. I wanted to take this as far as I could so I went about making various bits of the code tables available without the need for POSTing so I could use the GET call as required by the
DOM load() method. So, now I was at the point of having FireFox support full browsing of the web application content, consistent view as compared to IE, and the much needed ability to actually perform simple and complex searching. We are only missing two things to make the solution as complete and well tuned as it is when run under IE... POSTing
XML and client-side caching are needed. Without being able to issue posts to the server outside of the normal navigation of the site you cannot execute any of the edit functionality (I will try and explain why at the bottom). Without the local caching of data the FireFox version will generate significantly more traffic of redundant data requests (I do count HTTP 304's as redundant in case you were thinking well that object will get served from the standard cache anyway).
The big one
XmlHttp, I needed to find a solution for this problem. Was it going to be an applet (grits teeth, spits, rinses mouth with soap [not the good kind of SOAP]), a browser plug-in/extension (wow, I just don't have that kind of time to throw about). Well, as it turns out,
Mozilla FireFox has built and included the XmlHttpRequest object! You certainly do have to
look hard for it or I am terrible at searching for things. It doesn't work quite the same as the MS version but it has all the basic underpinnings required to make POST requests to the server without requiring the browser navigation method, iframes, or any other dirty little tricks. I still haven't found a replacement for the "userdata" behaviour supported by Microsoft but the entire web application is now consumable using either IE6 or Mozilla.
The summary... FireFox (and Mozilla) have made some really big steps forward in bringing the browser up to par with Internet Explorer (and in many cases, well past). They have covered off the #1 and #2 reasons I would ever solely target Internet Explorer and I know from this point forward I will alway try to keep my development efforts capable of supporting both even if the client is still remaining with IE. I am really looking forward to the next release of IE and a renewed browser battle.
I had mentioned that I would explain why the edit functions would never work unless I could get the XmlHttp bits replicated in FireFox. To understand this you need to get a feel for how the web application is designed with regard to content review (viewing/printing) and content contribution (edit). The system is designed to allow a user to locate one or more "tickets" and have them displayed in a summarized list that is suitable (and css styled) for printing. Additionally, a user can view
all tickets that matched the search criteria in complete detail that is again suitable for printing. So, the normal view of the application is that it looks completely read-only and "ready-for-print." When you have the detailed list of tickets displayed you can click the edit link for any of the tickets and the client-side code will "reshape" only that ticket so that you have a complete editing environment so you can alter the allowed properties and attach new notes or file attachments. When you do this any un-cached support code tables get retrieved and all the combo boxes, edit controls, etc. are revealed. When you are finished with your changes you click the save button and the client-side code does it's bit, builds the
XML request, and fires it off to the server. Whatis important here was that if you have a long list of tickets you are not going to requery the server for any of those details simply because you had updated a single ticket. It is also important that the user doesn't need to visit another screen (and cause more client-server round-trips) to perform the edit. All the goodies are either right there or they are brought to the client as required. Perhaps the most significant driving force for this design was when I put the application together I had just taken over a project that had a backlog of 300+ tickets that had not been entered, had 1500+ open tickets, and I had to manage a massive quantity of tickets quickly and efficiently when distributing them amongst resources. The application was fun to write back then and it was fun and educational to upgrade it to support FireFox this time round.
Thanks for reading if you made it this far :-).
Labels: Web
