n-Tiered AJAX is one of my my
favorite development architectures. It’s how I developed Gevalum, and
it’s how I’ll develop every website to come that has to touch a
database, but doesn’t require a full-scale ASP.NET application
platform. It’s fast, it’s scalable, and in the end, you’ve got one
sweet site with amazing processing efficiency and pizazz. It’s a pretty simple idea. This is how I develop:

First
off: make a mockup of the design. Figure out what you want it to look
like; draw it up in Photoshop, or write up the CSS in notepad, or
however you’re doing what you do. Make a note of every bit of static
information, and every bit of dynamic information, and dump it all into
DIV tags.

Next, after the interface tier, comes the big part:
your JavaScript tier. There are three distinct parts to this, although
you may only require two.

Part 1: your object layer. If you have
things like I do (players, items, etc) you’ll want to make objects. An
example would be a player object, with player.strength, player.health,
player.level, player.name… etc. A variable for every bit of connected
information on your page.

Part 2: your update layer. Make a
library of functions for each bit of information that you update. Don’t
directly call the AJAX here; update the objects you made, or use these
as a wrapper to validate then call your AJAX functions. You’ll probably
want to include some DOM functions like:

function $(div){
return document.getElementById(div);
}

and interface updater functions like:

function updateStats(){
$(“playerStr”).innerHTML = player.str;
//etc for all other stats
}

and variable updater functions like:

function uSTR(newStr){
player.str = newStr
}
and
anything else that your page does. Try to keep everything seperated; at
a minimum, I always have a dom.js, functions.js, and then finally
AJAX.js. You’ll call your AJAX layer by using something like this:

function uSTR(){
player.str = evalAJAXPost(“playerstats.php?stat=str”);
}

Part
3: Your AJAX layer. These are the functions that use your server-side
pages. You always want to separate these because they’re things you use
over, and over, and over again. Another trick that I learned a while
ago, is that if you have simultaneous updates (e.g. sending dynamic
updates while requesting pages), make an array of AJAX objects, and
pass each page request through a different object. I’ve found that
there’s no need for more than two or three (even Gevalum only has
seven, and that’s probably overkill.) This is an excerpt from Gevalum’s
AJAXFun.js:

var ajaxes = new Array();
//if we’re FF
if(window.XMLHttpRequest){
ajaxes[0] = new XMLHttpRequest();
ajaxes[1] = new XMLHttpRequest();
ajaxes[2] = new XMLHttpRequest();
ajaxes[3] = new XMLHttpRequest();
ajaxes[4] = new XMLHttpRequest();
ajaxes[5] = new XMLHttpRequest();
ajaxes[6] = new XMLHttpRequest();
//or, if we’re IE
}else if(window.ActiveXObject){
ajaxes[0] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[1] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[2] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[3] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[4] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[5] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[6] = new ActiveXObject(“Microsoft.XMLHTTP”);
}

function evalAJAXHtml(source,nr){
ajaxes[nr].open(“GET”,source,true);
ajaxes[nr].onreadystatechange = function(){
try{
if(ajaxes[nr].readyState==4){
if (ajaxes[nr].status == 200){
eval(ajaxes[nr].responseText);
}
}
}
catch(e){
//Exception-bug in FF
}
}
ajaxes[nr].send(null);
}

function evalpostAJAXHtml(source,datan,nr){
ajaxes[nr].open(“POST”,source,true);
ajaxes[nr].setRequestHeader(“Content-type”, “application/x-www-form-urlencoded”);
ajaxes[nr].setRequestHeader(“Content-length”, datan.length);
ajaxes[nr].setRequestHeader(“Connection”, “close”);
ajaxes[nr].onreadystatechange = function(){
try{
if(ajaxes[nr].readyState==4){
if (ajaxes[nr].status == 200){
eval(ajaxes[nr].responseText);
}
}
}
catch(e){
//Exception-bug in FF
}
}
ajaxes[nr].send(datan);
}

Now,
for the server-side part of this AJAX tiered application. There are a
thousand ways to do this, depending on personal taste; I choose PHP,
since it’s lightweight. You could use ruby, or asp, or asp.net, or
anything that outputs text. All I have to do is pull the information I
need, and write out my JavaScript updater function, and I’m done.

You
may be asking: why bother? Well, the easiest is that it’s the absolute
fastest way to get information securely from a database to the client.
It sends the minimum information possible, and so saves you bandwidth.
It’s invaluable for a little hosted server, or if you’re hosting
yourself and can’t afford a business-class internet line. Not to
mention, it’s faster on the user’s end, so they wait less, making them
less likely to turn away from some lag-o-licious old monolith of a
website. It’s streamlined, it’s dynamic; what else could you ask for?

Tags: , , , ,