This news has a big impact on all new browsers, but especially Google Chrome (a very similar competitor) because there is now no compelling reason to use or anticipate (Mac version) it; most of its differentiating features from Safari 3 have been matched and exceeded in Safari 4. Safari appears to run separate processes in each tab, it has a bytecode JavaScript engine, has a Google Gears like database implementation, and it obviously uses the Webkit engine. Additionally, it is the first and only browser to pass the Acid3 test to date.

This release is a huge step forward for Apple in not only the computer browser market, but eventually in the mobile browser market as well; imagine what the iPhone implementation of Safari 4 will bring.

Normally, I would write C# code that looks like this:

// Hard-coded for example
string status = "ww";

if (status == "ww" || status == "r" || status == "bw" ||
    status == "nb" || status == "qb" || status == "nt")
{
	// do something interesting
}
else if...
else if...
else...

However, after my hands tired out from typing (even with intellisense), I came up with the following:

// Hard-coded for example
string status = "ww";

if (new[] { "ww", "r", "bw", "nb", "qb", "nt" }.Contains(status))
{
    // do something interesting
}
else if...
else if...
else...

If the array of values contains an equal value to the status, then success. As you can see, the code is much easier to read and requires less typing. Enjoy!

[Update: Changed to use implicitly typed array (requires C# 3.0) instead of List<string>. Thanks manitra!]

var az = function() {
    var variable1 = "test";
    var variable2 = "test2";

    function testFunc() {
        alert(variable1);
    }

    return {
        init : function() {
            testFunc();
            this.testFunc2();
        },

        testFunc2 : function() {
            alert(variable2);
        }
    };
}();

az.init();

Let’s take a look at this in more detail!

You’ll notice that we have variable1 and variable2. These variables can be thought of as private variables. Additionally, testFunc can be thought of as a private function.

Any of the code that lives within the return block can be thought of as public. These are the only functions that may be called externally. If you are calling a public function within the class, you must either put the full path to it (ex: az.testFunc2()) or prepend it with this (ex: this.testFunc2()).

So now you have a good example of how to represent a class in Javascript. But let’s take this a step further and emulate namespacing as well.

Let’s say we had the code above in addition to this code below:

var az.util = function() {
    return {
        gebi : function(obj) {
            return document.getElementById(obj);
        }
    };
}();

Now we can call az.util.gebi('id_to_get_element_of').

You can keep adding level after level to the namespacing so that you might have something like az.util.date.convert.toSql().

Using this technique is great because you do not junk up your global namespace and you can organize your code very well. In fact, each different “class” can live in its own file and you can create a mechanism to import the files as you need them (dramatically improving load time).

An interesting note: You may notice on the examples that there is not a line break between return and the opening brace. Adding a line break will cause the code to break (who knows why?!). Therefore, you will have to keep the opening brace on the same line as the return.

dojo.widget.createWidget('tooltip', {
	caption: 'what you want the tooltip to say',
	connectId: 'target_id_to_attach_tooltip'
});

However, this is not complete because we need to attach it to the body of the document like this:

var new_tooltip = dojo.widget.createWidget('tooltip', {
	caption: 'what you want the tooltip to say',
	connectId: 'target_id_to_attach_tooltip'
});
document.body.attachChild(new_tooltip.domNode);

You’ll notice that the return value of dojo.widget.createWidget is an object and when we attach it to the body of the document, we use the domNode property of that object.

There is one more potential problem with dynamically creating these widgets. Let’s say that we have a dynamic table and each row of the table contains the target id for each tooltip. If the table gets reloaded with new data (rows have new ids), the old tooltips remain appended to the body. No big deal of you don’t mind a little trash left behind, but the problem comes into play when you load data back into that dynamic table that may have previously existed and generate a whole new set of tooltips to go along with it. Now you may have two or more of the same tooltip appended to the body that belong to the same target id. Some browsers might be fine with this and some might choke. To prevent these duplicates, we use the following code for each new tooltip widget that is created:

function createTooltip(target_id, content) {

	// prepending 'tt_' to distinguish between target and tooltip id's
	var obj = document.getElementById('tt_'+target_id);

	if(obj != null)
		obj.parentNode.removeChild(obj);

	var tooltip = dojo.widget.createWidget('tooltip', {
		caption: content,
		connectId: target_id
	});

	tooltip.domNode.id = 'tt_'+target_id;
	document.body.appendChild(tooltip.domNode);
}

You might notice that we are actually adding an ID to the tooltip. This allows us to check in the future if that tooltip has already been created. If it has, the code above will destroy it and create a new tooltip in its place. This should assist those searching for answers about dynamically creating dojo tooltip widgets.

The Acid2 Test was developed by the Web Standards Project as a means to help vendors test their browsers so that they are compliant with Web Standards. For a good laugh, try the Acid2 test with IE6 or IE7 (either one, they both render it terribly).

Also, Steve Jobs showed off the upcoming Mac OS 10.5 (Leopard) at the WWDC and it looks absolutely incredible. I need not explain it here, just check out the link and prepare to be amazed.