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.

One of the key focuses of our research has been making the switch from PHP to one of the cool new Web 2.0 frameworks/languages for all of our future (and top secret) web apps. The two contenders are Django (Python-based) and Ruby on Rails (Ruby-based {as you might have assumed…}). We are still torn, but a decision will be reached quite soon.

Also, we have been hard at work developing a new Javascript framework to clean up many of the namespace polluting functions that we already have. Yes, we are ashamed it took this long, but at least we are making the leap.

Aside from the all of the projects we are working on for our many happy and wonderful clients, we have begun strategizing a fresh new AzroTech Update. It is going to be even more amazingly simple to use and will also allow for portability. That means you can still enjoy the benefits of AZ Update even if you don’t host with us.

Finally, do yourself a favor and add the AzroTech blog to your RSS aggregator. We are launching a new initiative to blog every day with updates and technical issues we run into while doing what we do. We will include topics from database development, new technologies, C#, PHP, Ruby, Python, CSS, and web standards. Tune in and enjoy!