(Back to beginning of series)

Part 3: Site Architecture Design

Now that I had the majority of the HTML and CSS down, I had more to figure out about how to implement the various features (like image gallery, news,and mailing list). Should I write my own, or should I use existing tools? What language should I use? What database system? Which pages should be static, which dynamic? The process of building he site was all about efficiency: getting the most done, using the best tools, in the least amount of time. That would allow me to focus as much time as possible in my before my deadline towards the things that will make a difference: site design, usability, and the the use of the features on the site.

I came with the conclusion that I could, and should, develop most of the data management using external tools. Spending time re-inventing the wheel and rebuilding tools that already have dedicated teams would be wasteful, especially when they all had some sort of hook (mostly RSS feeds) that I could just pull into the site. I was familiar with all the 3rd party tools I needed, so I was already comfortable with using them and knew they had the features that I needed. I came up with:

• Google Apps for email and calendar
  • Here’s a good tutorial. It was a little messy at first, but it gives you an iframe (the only standards-breaking thing on the site… thanks, Goog) that you can just drop in.
• Picasa for photo gallery
  • I chose Picasa for a few reasons, the largest of which was the integration of the Google Apps account. While there’s no “Picasa” section of Google Apps, I could use the account I set up to minimize the logins I’m using, now that I’m using four tools. I used the RSS feed to export to the image gallery and to make an image gallery  RSS link on the home page.
• WordPress for dynamic pages and news
  • The reason I used WordPress, and I didn’t just slap together my own editor, was the WCM Page Feeder plugin. It allows you to serve individual WordPress pages as an RSS feed. This means that I could use WP’s superior news-serving tools along with their page editing tools with very simple integration. I also added an RSS link to the home page, for news.
• Pommo for mailing list management
  • I tried out a few tools, and found this to be the easiest to set up. Makes adding an email form pretty simple, manages everything for me. Another several hours saved to these guys. Here’s some credit

I also used a couple 3rd party PHP Libraries so that I could hook all of this lovliness together:

• Simplepie RSS Reader
  • Note: I had to switch my WordPress RSS feeds over to Atom, even though SP claims it can read the RSS 2.0 standard. This was a simple checkbox in the “Writing” section of the WordPress settings.
• phpmailer for mail functions
  • A little messy to set up to go through Google Apps mail. I had to set these settings in class.phpmailer.php in order to connect without errors. Once you have this part right, though, you’re good to go. I’ll go into more detail about this in the next article.

Once all of these tools were in place, it was a simple matter of dumping their content, using Simplepie, into my template. I’ll talk about the actual hooking up of everything, and setting up the custom code I did write, in the next article.

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?