FC IE7, AJAX, and ActiveX  

« Salesforce.com AppExchange - Embrace Developers | Main | Home Again »

IE7, AJAX, and ActiveX

I have been running the IE7 Beta 1 for the last week or so (Asite is a Microsoft Partner so we get this through MSDN) and I can't say I've been altogether pleased by it. The first thing that happened within half an hour of running it was that I got my first Blue Screen of Death in recent memory (on my WinXP SP2 laptop). Not an auspicious start. Since then it hasn't caused any machine-crashing errors but there are still a number of niggles to it that I don't like and overall it gives me no compelling reason to want to move from Firefox.

This post, however, is not meant to be a review of IE7 Beta 1 (As per the rumour mill, Beta 2 should be expected soon enough). Instead this is a question from the development team at Asite to the IE7 team at Microsoft.

On Monday, Sunava Dutta from the IE team posted this entry in the IEblog about Native support for the XmlHttpRequest object in IE7. This is very good news (Thanks Sunava!) In both the IE 6 and IE 5 release lines the XmlHttpRequest object was implemented as an ActiveX control - meaning that client browsers were required to allow trusted ActiveX in order to make use of functionality using asynchronous xml calls over http.

Generally, this is not a problem as the DLL used for this functionality is internal to IE and is actually installed with the browser itself. Some users, however, operate under a very strict lockdown on client machines - including blocking of any and all activeX controls - external, internal, trusted, or not. For these guys this creates a problem in that XmlHttpRequest does not work!

Now, this news is good because it will simplify the development process for Ajax developers going forward (in the distant future when IE 6 is no longer used) - however it is not really that major of a deal for the moment - as there is an existing workaround using IFrames in IE which works ok anyway. Plus Mozilla/Firefox already offer native support for this object.

There is another object in the browser which is also fairly integral to the implementation of AJAX (at least the way we do Ajax), and that is the XSLTProcessor object. In pseudo-layman's terms - this is the object that a developer can use to take an xml data feed on the one hand and an XSL stylesheet on the other hand - and push the xml through the stylesheet, outputting some third format - in our case the format is HTML and javascript which then gets rendered to the screen.

This has been done for ages in web apps - on the server side. In the Java world we usually use a framework called Xalan (at least I do) that was implemented sometime back before I started using it in the mid-90s. Only over the last couple of years has it become feasible to do this on the client-side in the browser itself.

The XSLTProcessor object works great - and it means that in a lot of places we are now able to asynchronously retrieve xml data and stylesheets ahead of time for pages which we know the user will be accessing (or is likely to be accessing) a couple of clicks before he gets there, and cache this data directly in memory on the browser. This means that when the user does make that click all of his data is already there and the transformation occurs nearly instantly right there on the client without even making a request to the server at all. Happy user, happy developers!

The problem comes with the XSLTProcessor object which is also an ActiveX control and so won’t work under lock-down either! Same as with the XmlHttpRequest object, in Mozilla/Firefox this object is already implemented natively and can be accessed via the DOM using Javascript. Check out the Sarissa implementation if you haven’t seen this before.

In order to make it work in these cases we either have to get them to change browsers or we have to leave them with server-side transformation. As software vendors we are unable to control the browser choices of our users (and unwilling to get involved frankly). So we have to provide a version for this platform which uses server-side transformation. I hope most will agree that moving away from the synchronous request-response style user interaction is the way we should be moving and that it should be available to the widest possible userbase.

So, my question to the IE team at Microsoft is this: Will you be supporting a native implementation of the XSLTProcessor object in IE7?

And to anybody else out there reading this: are there any other workarounds to this?

Leave a comment

Copyright © Nathan R. Doughty 1994-2005