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!

Eventually I found my home in a real language, C. It was then that I was first confronted with the issue of formatting. My early code looked a little like this (and yes, I’m ashamed):

static void testfunc()
{
int j = 0;
 
for(int i=0; i<50; i++)
{
j = i + j;
}
}

My thought at the time was, “I’m smart enough to be able to read this code and decipher it later.” My ignorance shined clearly a few months later when I went back in search of a previously written function and found it almost impossible to alter (because it was about a hundred lines worth of code formatted like the example above).

However, this post is not about my ignorance as a young programmer, but rather an attempt to pass on a type of code formatting that I, and all of the others at AzroTech, have found quite clean and the most readable over any other type of formatting we have played around with. NOTE: I do not maintain this is the BEST way of code formatting nor do I pretend to be the first or only person to do it this way, but rather I wish to share with others what works so well for us.

My college professor, a man named Dr. Eland was the first one to show the differences in code formatting and we were actually required to write our code his way (which is the way I want to show you). He gave us three examples of code formatting, which I will show using the PHP language.

Example 1:

function testfunc() {
   $j = 0;
 
   for($i=0; $i<50; $i++) {
      $j = $i + j;
      echo $j;
   }
}

Example 2:

function testfunc()
{
   $j = 0;
 
   for($i=0; $i<50; $i++) 
   {
      $j = $i + j;
      echo $j;
   }
}

Example 3:

function testfunc()
   {
   $j = 0;
 
   for($i=0; $i<50; $i++) 
      {
      $j = $i + j;
      echo $j;
      }
   }

From a majority of the source code that I have read from other programmers, Example 1 is by far the most commonly used formatting out there (and in my opinion the WORST). The problem with this type of code formatting is that the curly braces are not even and it becomes very difficult to match up braces (at least until you train yourself to read code like an alien). Our professor explained to us that code formatted like this was born back when keeping file sizes down was a concern. I would say that it’s worth to take the extra space to avoid this type of formatting!

Example 2 bring us closer to better formatting, but it too has a drawback. It does address the issue of matching up braces but fails to truly express the logical hierarchy of the code. For example, what I mean by this statement is that the code within a function, called a code block, should be thought of as a child of that function. When your eyes are scanning through thousands of lines of code, you are generally searching by a function’s identifier and not it’s underlying code. When you are searching, the braces directly under the function declaration header will make it difficult to differentiate between the header and the code block.

Out of all of these methods, Example 3 is the way we prefer to do it at AzroTech. It provides the best of both of the previous examples: matched braces and differentiation between the header and the code. Programming can be difficult enough at times and by formatting our code this way, we have never struggled trying to determine which code blocks belong where. Like my professor years ago, I require our programmers to use this method of code formatting.

Properly formatted code can make you a better programmer! It would be nice if the whole world could just trust us an try programming this way for at least 30 days, but I know that probably isn’t going to happen. This whole post is not intended to be a rant but rather a glimpse into the development techniques of AzroTech. Hope you enjoyed it!