brentashley

Michael Mahemoff talks about Ajax transport layers and their problems.

In my Ajax Experience presentation last month, I covered all the available transport layers, their history, pros and cons, and provided some example code. My main intention in doing so was to demonstrate that there has been over 8 years of evolution of Ajax-related techniques to bring us to where we are, and to underline that Ajax is not a done deal, there is still work to be done.

The ReadyState 3 issue that Michael talks about has been well known (well, apparently not well known) at least since Scott Andrew LePera described the problem in late 2002. It really needs to be fixed.

Cross-domain issues also still need to be addressed. I spoke to Brendan Eich from Mozilla about this at the conference and he mentioned that there are other W3C specs that use access control lists, which may provide an existing base upon which to build an XMLHttpRequest ACL model. Laurel Reitman on the IE7 Team was also involved in discussions about this issue.

Douglas Crockford‘s JSONRequest proposal goes a long way towards suggesting solutions to the various limitations of the current state of available Ajax transport layers.

Jesse James Garrett communicated very clearly in his keynote that Ajax is no longer an acronym to be limited to its original initials. According to Jesse, as long as these two basic ingredients are involved, what you have is an Ajax application.

• asynchronous interaction model
• browser-native technologies

Hopefully, organizations like the new OpenAjax Alliance will be able to reach consensus on what needs to be done and how in order to take us to the next level in Rich Internet Application evolution.

(via James McFarlane) For those of you (and I know there are many) who find it difficult to understand Sam Stephenson‘s Prototype library without a definitive roadmap or documentation, there is a new Google Groups Prototypejs group where you can at least commiserate with others in the the same boat, and at best share tips and collaborate.

Through working with the IE7 team, we’ve figured out the problem behind the IE7 XMLHttp resend issue I reported a while ago.

The short answer is this – we’ve demonstrated that in our app at least, IE7 resends its XMLHttpRequest data if you use the ActiveX XHR object, but works correctly if you use the native IE7 XHR object. Be sure that your XHR-creation code uses “new XMLHttpRequest()” to invoke the object in IE7 and you will not have the problem.

Tim Aiello explains in more detail.

I have seen a lot of griping over the years about an imagined scarcity of debugging tools for IE. I find it remarkable that people in the business don’t know what’s available.

Microsoft has had great debugging tools for IE since Visual Interdev as far back as 1998 or so and continuing through to Visual Studio. The visual studio debugger has breakpoints, watch variables, call stack, step in/out/over, object browsing, immediate window, debug output window, and more.

If you didn’t want or need an entire IDE, Microsoft Script Debugger became available as a download for NT4 and Win98/ME, later becoming a component delivered with Windows operating systems as of Windows 2000 that simply required enabling. The Script Debugger is a lot lighter than the VS debugger, but still has breakpoints, watch variables, call stack, step in/out/over, immediate window, and debug output window.

Now Microsoft has released their Visual Web Developer Express IDE for free. Install it, then in your browser’s advanced options, uncheck the two boxes that disable debugging, and you have a debugger that is every bit as powerful as Mozilla’s Venkman ever was.

Here is a screenshot of a simple single-page debug session (click to open full size):

No wonder it took so long for Javascript to get any respect if people didn’t know that there were decent tools for it.