Pankaj Kumar's Weblog

After learning about Zimbra at Slashdot, I watched their flash demo and even went for a test drive. Even managed to take a screen-shot of a message that I typed-in:

Notice the miniaturized image of my homepage! isn't it cool!

One more proof-point that future of client software belongs to AJAX.

Came across AJAX Patterns site and an O'Reilly book in the making. The most comprehensive and well written collection of AJAX tips and tricks I have come across so far. Besides that, there are a number of other aspects worth mentioning: it is being developed and edited using a WikiMedia software, the same software that powers Wikipedia, in a collaborative manner; the text is available under Creative Commons license; makes good use of Web technologies for intra- and inter-linking; and allows audience to participate in the content creation.

So far most authors and publishers have tried to publish content developed for print media on the web -- either PDF e-books or Safari style transformation (can't think of a better word) of the same content. Safari books are certainly much better for online perusal but neither take full advantage of the Web's potential. Ajax Patterns book is taking a different route -- it is not only getting created with help of Web technologies but is also architected for Web perusal. In fact I have a feeling that the author first got the idea of creating the content in this manner and the O'Relly book came as an afterthought. It would be interesting to see how this Web-centric content translates into printed material.

A number of AJAX libraries and frameworks have emerged to purportedly simplify development of Rich Internet Apps, though none can substitute, at least not yet, a good understanding of what are the recurring problems, potential solutions and what goes on behind the sleek facade of a browser to power these hot and sexy Apps. This is best said by Michael Mahemoff, author of Ajax Design Patterns, in his blog post of May 8, 2005, which eventually became the basis for a popular Wiki on Ajax Patterns and later, this book.

Careful design is always required, and it must be based specifically on the technology at hand. As AJAX emerges, we’re going to learn more about what sort of design works, and we’ll need ways of documenting this information and talking about it. Fortunately, the evolution of this particular technology will take place at a time when design patterns are well-entrenched in the industry, and design patterns are an excellent means of knowledge representation.

Hoping to save some time, I decided to use the JavaScript Cookie class provided in the otherwise excellent book JavaScript: The Definitive Guide, 5th Edition. However, my program was not working as intended -- the cookies that were supposed to last the whole session were getting reset at every new page. After an hour of alert() and FireBug assisted debugging finally helped me to track down the problem: the Cookie class was not behaving properly. Just submitted an errata to O'reilly's. Here is the submission:

document.cookie value on FireFox includes a blank space after ';'. As a result, the code to extract a particular cookie value doesn't work:

    var cookies = allcookies.split(';');
    var cookie = null;
    for(var i = 0; i < cookies.length; i++) {
        // Does this cookie string begin with the name we want?
        if (cookies[i].substring(0, name.length+1) == (name + "=")) {
            cookie = cookies[i];
            break;
        }
    }

This can be easily fixed by first replacing all blanks with zero length strings, as in:

    var cookies = allcookies.replace(" ", "").split(';');

My program is happy now.

John Resig's blog post on Flexible Javascript Events presents cross-browser functions to register and deregister DOM events to/from any DOM element: addEvent() and removeEvent(). He wrote these functions in response to a addEvent() recoding contest, that was published at a well-known site for Web developers run by Peter-Paul Koch and included Scott Andrew LePera, Dean Edwards and John Resig himself as co-judges. The recoding contest itself was a response to wide interest in his blog post addEvent() considered harmful where he outlined a problem with a widely used function addEvent() published by Scott Andrew LePera. It should also be noted that John Resig's entry was judged as the winner entry.

Most web developers are familiar with the names mentioned in the previous paragraph. They have published books, maintain highly visible websites (Google PageRank of websites/blogs maintained by Peter-Paul Koch, Dean Edwards, John Resig, Scott Andrew LePera are 9, 8, 7 and 7, respectively at the time of this blog post), blog regularly and are generally considered gurus in the area of client side web development.

I add all this background only to make the point that writing cross-browser DOM event handling code is non-trivial and has attracted the attention of best minds in the field. With that feeling of comfort that comes with being in good hands, one would think that the problem, although considered difficult in the past, has been solved once and for all and can be reused without much thought.

At least this is what I thought till some strange behavior in my AJAX code that used John Resig's winning addEvent() and removeEvent() forced me to analyze each and every line of the whole program and discovered a couple of really interesting things about the addEvent() function. But before I get into my discovery, let us take a look at the addEvent() code from John Resig's page:

function addEvent( obj, type, fn ) { 
  if ( obj.attachEvent ) { 
    obj['e'+type+fn] = fn; 
    obj[type+fn] = function()
      {obj['e'+type+fn]( window.event );} 
    obj.attachEvent( 'on'+type, obj[type+fn] ); 
  } else 
    obj.addEventListener( type, fn, false ); 
}

As you can see, this code takes on two issues with IE's support for DOM events: (a) IE uses a non-standard method attachEvent() to register event handlers; and (b) it runs the handler code in the global context (ie; built-in variable this is set to window object during handler execution) and not in the context of the element to which the handler is registered.

The removeEvent() code is very similar and doesn't need to be reproduced here.

So, what is the problem? Actually, none whatsoever, at least not until you have an event handler function that is few tens of lines long and you pass the name of the function as the last argument to addEvent() function. If you are like me, you would think that the code will either use the function name string or some kind of address to create a short string as key to store the handler function reference within the DOM element object. But what really happens is that whole text of the handler function consisting of few tens of lines of code becomes part of the key (key is 'on' + type + fn). In my code I had a key with length greater than 2000! This in itself would not be much of a problem if the key was created only once during registration and then used for lookup during handler execution, though even a lookup in a hash table with very long strings is probably going to tax the JavaScript interpreter badly. The killer is that the key gets created every time the handler is run. This could be very frequent if the event type is 'mousemove' and could easily result in excessive memory use and sluggish behavior.

"This doesn't sound like an insurmountable problem," you may say, "just wrap your long function within another function that simply invokes the long function. This way the addEvent() code will use the body of the wrapper function for forming the key and avoid creation of long strings."

Actually, this is very similar to what I tried, my motivation bring two-fold: reduce the length of the code that gets used as part of the key and also pass an argument at the time of event handler registration. The wrapper creation function looked something like this:

function create_handler(func, arg1){
  return function(event){ 
    return lfunc.call(null, 
      event || window.event, arg1); 
  }
}

And I used it as follows:

function long_function(event, arg1){
 ... tens of lines of code ...
}
addEvent(obj, 'mousemove', 
  create_handler(long_function, arg1));

which, actually, ended up creating this fixed text for every function: "function(event){ return lfunc.call(null, event || window.event, arg1); }". As the key is a created by concatenating the even type and function text, same key will be created for different handlers if the event type remains same, causing overwrite! This actually happened in my code!

So, even the winning entry has skeletons in the cupboard. It is not that every use would result in broken programs, but there certainly are situations where they fall short. In fact, this is true for most library function and it is always a good practice to know not only the interface and purpose but also the underlying assumptions and how the thing actually works. To be fair to the author John Resig, the recoding contest post had a strict set of requirements and being a reusable function under different conditions was not one of those.

Okay, a short blog post like this (or even a big one, like those penned by Steve Yegge) can't tell you everything *known today* about Ajax, forget "all you ever need to know". In fact, it can't tell you everything about anything worth knowing. There is just way too much information and knowledge around us about almost everything, consequential or not. To make things worse, at least for those who claim to "tell everything", this body of information and knowledge keeps growing every minue.

So why did I choose this particular title? No, I didn't intend to write everything I know about Ajax. It is just a link-bait. Seems to have worked quite well for others. Might work for me as well.

What I really want to do in this post is to write a short review of "Ajax -- The Definitive Guide", a book published by O'Reilly. Those who are familiar with Oreilly's The Definitive Guide series know that these books have a reputation of being very comprehensive and all encompassing about the chosen topic. This certainly seems to be the case for a number of books in this series on my bookshelf, such as "JavaScript: The Definitive Guide" and "SSH, The Secure Shell: The Definitive Guide". But a definitive guide on something like Ajax? It would have to cover a lot of stuff, in all their fullness and fine details, to do justice to the title: the basics of Ajax interactions, (X)HTML, JavaScript, XML, XmlHttpRequest, CSS, DOM, browser idiosyncrasies, Ajax programming style and design patterns, tips-n-tricks, numerous browser side Ajax libraries such as prototype, YUI library, jQuery etc. and their integration with server side frameworks such as RoR, Drupal etc. The list is fairly long, if not endless. And each topic worthy of a book by itself.

Fortunately, Ajax -- The Definitive Guide doesn't try to be a definitive guide for everything that goes or could go into an Ajaxy application. I found the book more to be a good collection of interesting and relevant topics that the author Anthony T. Holdener III has had first hand experience with. Most of these I knew about, some I was vaguely familiar with and a few were quite new to me. However, I wouldn't call the collection a "definitive guide for Ajax". If you are new to Ajax and are somewhat lost, in terms of where to start and how things relate to each other, then this book is certainly worth paying for. However, if you have already been into Ajax development for sometime and are craving for a single text to answer recurring questions around Ajax specific patterns, solution to common problems, browser differences and ways to tackle them then this is perhaps not the book for you. In this sense, the book doesn't really fit into the "The Definitive Guide" pattern.

On the other hand, the book does provide good introduction to basic concepts, is quite readable, includes a lot of source code for non-trivial working programs and lists relevant resources, such as Ajax libraries, frameworks and applications, in its References section. I especially liked the "chat" and "whiteboard" application that allows two or more users to share a whiteboard and chat through their browsers.

Okay, so how does this book compares with other books on the same topic? This is a tough question, for I haven't been paying attention to most books that have come out on this topic. Though there is a answer, and it comes from this Amazon Sales Rank comparison chart:

A higher Sales Rank for an item implies that more people are buying it from Amazon. This doesn't tell how well a particular book will meet your needs but just that the high ranking items, in general, are being bought by more people than the low ranking ones. The above chart does indicate that Ajax -- The Definitive Guide is outselling its rivals, at least at the time of this review (March 17-18, 2008).