I still love them, but I have some caveats with regards to using them for non-singleton objects.

First, what is a module?

var counter = function(){
    var my = {
        count: 0,
        max: 5,
        isPastMax: function(){
            return this.count > this.max;
        }
    };
    //This is what gets assigned to the variable "counter"
    return {
        getCount: function(){
            return my.count;
        },
        reset: function(){
            my.count = 0;
        },
        increment: function(){
            my.count++;
            if (my.isPastMax()) {
                this.reset();
            }
        }
    };
}(); //NOTE the (). That makes the outer function run and return immediately

A module is nothing more than a function which returns a public API object which, through the magic of closure, has access to truly private methods and variables. Here I’ve put them all as properties of private variable my.

counter is now a singleton object that maintains a counter state privately. No more methods can be added to it which reach anything in my that we haven’t explicitly allowed.

This is all well and good. But what if we want more than one counter? Let’s take off the trailing () so that we have a factory that produces counters:

var Counter = function(){
   //just as above
}; //NOTE the absence of ()!
var instances = [];
for (var i=0; i<100; i++) {
    instances.push(Counter());
}

Now we have 100 instances of the Counter module!

Unfortunately, the encapsulation has come with a price in this case. Every function we defined within Counter has to be created again and occupy more memory!

Sometimes this is acceptable, if the number to be created is low and the module is small. If you’ve got a module that goes on for a few pages and you intend to make a few dozen instances, expect to be eating up substantially more memory than a similar feature using a non-encapsulated object, like so:

var Counter = {
    _count: 0,
    _max: 5,
    _isPastMax: function(){
        return this._count > this._max;
    },
    reset: function(){
        this._count = 0;
    },
    increment: function(){
        this._count++;
    },
    getCount: function(){
        return this._count;
    }
};
Object.extend = Object.extend || function(a, b){
    for (var k in b) {
        if (b.hasOwnProperty(k)) { a[k] = b[k]; }
    }
    return a;
};
var instances = [];
for (var i=0; i<100; i++) {
    instances.push(
        Object.extend({}, Counter)
    );
}

All of the functions exist only once in memory, referenced by the individual instance objects.

Make no doubt: the module pattern is a tool that every good Javascript developer should understand. It provides excellent encapsulation that can’t be externally broken. It’s not without its drawbacks, however.

What’s amazing is that I’ve had some degree of success with it. I can’t show a demo yet, but imagine that a fully animated, complicated application smoothly scales, centres, and otherwise behaves more or less like you’d expect Flash to.

To be sure, there are some sketchy areas. Webkit’s positioning math can be very sloppy if you need precision (my design does). Any container that’s affected by font size is going to change a little (not always bad).

Watch here for a demonstration of this soon, along with a bit of how-to.

Looking through the jQuery core, I found that the problem is that “status” field isn’t sent to the handler. A simple intervention on jQuery.handleError will close the gap:

jQuery.handleErrorOriginal = $.handleError;
jQuery.handleError = function( s, xhr, status, e ){
  if (s.global) {
    xhr.error_status = status;
  }
  jQuery.handleErrorOriginal.apply(this, arguments);
};

The “e” object is the original ajax configuration object. Since it reaches the global ajaxError listener, we can pull the status out of that.

Notice that I don’t replace the original functionality, I just do something before calling it with the same scope and arguments. The reason here is forwards-compatibility. Assuming that the name and api of jQuery.handleError doesn’t change, any changes to its internal functionality in future updates will likely be preserved without refactoring effort on your part.

To catch the errors:

$("html").ajaxError(function(xhr, s, e){
    var msg;
    switch (s.error_status) {
      case "parsererror":
        msg = "A JSON parsing error occurred.";
        break;
      case "timeout":
        msg = "An ajax request timed out.";
        break;
      default:
        msg = "An ajax error occurred.";
        break;
    }
    alert(msg + "\n\n" + e.url);
});

Why do I set xhr.error_status and then read s.error_status? Because, somewhere in the jumble of handleError and trigger, xhr becomes s. I love jQuery, but some of its core code can be quite difficult to read through.

After a fair bit of futzing around in my code and the jQuery core library, I discovered that in chrome 4 in certain cases (probably in large apps), the DOMContentLoaded event was never sent to the core jQuery library. To test this, I inserted a couple of lines into the file you saw above:

3052  if ( document.addEventListener ) {
3053      // Use the handy event callback
[ins]     alert("jQ adding listener for DOMContentLoaded");
3054      document.addEventListener( "DOMContentLoaded", function(){
[ins]         alert("jQ received DOMContentLoaded event");
3055          document.removeEventListener( "DOMContentLoaded", arguments.callee, false );
3056          jQuery.ready();
3057      }, false );

Both alerts show in FF, but only the first does in chrome. However, I found I could add my own and have them called.

Now, since the chances are you’re on this page because you googled for a workaround, here it is:

Google Chrome 4 beta jQuery document ready fix plugin

What this plugin does is first test to see if the browser is chrome 4, and if it is, then it adds another event listener for DOMContentLoaded, which will run even though the main jQuery one mysteriously does not. This calls jQuery.ready function (which is what is used to run through jQuery.readyList, the queued functions array).

We now have two chances for jQuery.ready to be called, therefore a potential race condition. To avoid this, I rewrote jQuery.ready() to null out  jQuery.readyList before cycling through the queued functions.

I still have no idea what’s causing Chrome 4 to fail on this. A test of document.readyState right after I added $(document).ready() shows that it is “loading”, so the problem isn’t that it finishes before adding the event handler or enqueueing the function.

In short, if you use innerHTML, innerText or outerHTML on most elements, IE will convert newlines to spaces. Checking the charCodes of newlines (whether unix or ascii) shows them as 32s.

On the other hand, if I output (in a template) the text inside a PRE element, IE will keep the newlines. An element styled with white-space:pre won’t do the trick.

In my case, I have a TD and inner DIV which contain a text string. I need to show the full text string, with line breaks, in a popup dialog. (The CSS property white-space:pre isn’t useful, since long lines can’t wrap at all.) My two realistic options are to copy the data into a JS variable or put the text initially inside a PRE element.

Got to love Microsoft. They keep us webdevs in a job.