This is why in this tutorial I’ll try to give you an idea on how the actual design works. I’ll be heavily relying on my last tutorial for the layout of the final application, but we’ll go much more into detail about the decisions we take. Some parts may be applicable to non-Web-2.0 Web design and some even come in handy when designing completely non-web related applications
User Requirements
This step is as important as the coding itself, if I’d start right with the code without first clarifying where I want to go, I’d be wasting time! So there are three important questions that I have to answer:
1. What? What do I (or my boss) want the application to be, what functionality is a must, what is an optional, what are “nice to have” features?
2. Why? Does what I have found that I want to implement fit into the context or would it fit better if I’d change it a bit?
3. When? Do I have to implement everything right now, or may I add some new features one after another, possibly by releasing it before everything is implemented? But much more important: In what order will I have to implement the functionality?
There is not really a point that is more important than the others, take your time documenting and analysing the problems that you expect and fix some priorities, it will greatly speed up the implementation later.
What & Why
We plan to make a community site so the obvious things for a community is that it has to be attractive, easy to use and most important “feel alive”, nobody really wants to be part of a dead community where some casual visitor posts a new message to the forum every few days. To archieve the live feeling we use some little tricks like the regular updates of the list of users that are currently online. Remember that a community is not made up by two or three moderators posting some news from time to time, and filling the Forum with Junk messages nobody cares about.
When
It is important to understand that we’re not delivering a half finished product, it is fully functional, we plan to add more features in a second (and maybe third) step
1. Release
1. Main engine: the basic framework which will allow us to load and execute single modules at a later time.
2. Display some static content.
3. News System
4. User Registration and simple profiles.
2. Release
1. Advanced profiles
2. Private messaging
3. more to come…
This list is off course fairly superficial and does not cover the details of the implementation, it is an abstract planning step, that helps us get a general overview
Under the hood
As mentioned before we don’t want to reinvent the wheel for the millionth time again so we’ll use some libraries:
1. Prototype: probably the most flexible and intuitive AJAX Library on the internet, really lightweight and easy to use.
2. Behaviour: helps us to keep our pages downgradable for browser without JavaScript support (important also for indexing by search engine).
3. script.aculo.us: what would a Web-2.0 application be without nice effects?
This is what we’ll use for the client side. For the server side we’ll use PHP which is nice enough for our purpose, and is a reasonable tradeoff between control, speed and abstractness. For client-server communication we’ll use JSON which allows us to directly encapsulate the data into a JavaScript object, thus making the interpretation of the data much easier, in this tutorial we’ll use the JSON-PHP Library.
The Behaviour Library allows us to bind functionality right to the DOM-Elements without having to add onclick, onload, on[whatever] handlers right in the HTML, it allows us to define some CSS Classes, associate them with certain actions and then the library will take care of the rest for us, fully automagically.
Another main problem with AJAX pages are the “one-page-application” (applications that run entirely on one page) that have some problems with Bookmarking and the famous back button, I decided that the community page will be implemented as a one page application because it makes the whole process much easier, everything runs in one context and we don’t have to care aabout the rest. But we also want to make our pages bookmarkable so we use the hash ending of the URL to identify which page we are currently on.
Basic setup
Ok, so it’s time for us to gather all our libraries and put them into our Project Folder. Our project directory structure looks like this:
The Javascript folder will contain our three libraries (prototype, behaviour and script.aculo.us), the lib directory will contain all our PHP libraries (just the JSON-PHP for now) and static will contain our non dynamic content, such as some welcome textes and help pages.
Implementation
Now we’ll finally getting to see the actual code, it is important that we go one step after another, starting from the basic page layout and then building the functionality on top of that, it will keep us motivated throughout the process to implement a little thing and then test it to see if it works as we’d expected. The base Page is just a Page with the basic content, possibly a welcome message that tells where the user landed and what this is all about. We’ll use a pretty standard Layout for our application, the only requirement for AJAX is that we assign some ID’s to the main parts so that we can easily reference them later. Now we can insert links as we would normally have done, browsers without JavaScript will see a classic page that is completely served by our PHP-Scripts on the server side. For example the first thing we’ll do is display some static, non generated content, like the Welcome page normal links would look like this:
About
The PHP page would take the query string Page/About and would then serve the new page. Now we want to add the AJAX Magic, and this is magic indeed: we’ll use behaviour to catch the request before it is being sent and use AJAX methods from there on to download only the updated regions of the page. First we have to add a Class to all our internal links:
About
this allows us to distinguish the links we want to catch from the links to outside resources, for which AJAX is not applicable anyway.
var rules = {
‘a.link’ : function(el){
// We don’t want to have garbled links…
if(el.onclick)
return;
Engine.log(“Applying rule to “ + el.toString());
var target = el.href.substring(el.href.indexOf(‘?’) + 1);
el.href = “#”+target;
el.onclick = function(event){
var targ;
if (!event) var event = window.event;
if (event.target) targ = event.target;
else if (event.srcElement) targ = event.srcElement;
if (targ.nodeType == 3) // defeat Safari bug
targ = targ.parentNode;
Engine.log(“Clicked on internal Link “ + targ.toString());
Engine.loadPage(targ.href);
return false;
}
}
};
Behaviour.register(rules);
By doing this we have defined how the user interacts with the AJAX Engine, every element that fires up a certain event will have a class, and behaviour will then take care of the hooking up. Off course the loadPage example isn’t a really complex one but it’s the most common interaction on our page, and it shows the important parts.
See what’s going on
To test and see if all is going as we designed it we will have some way to get feedback from what we do on our Page. Using the alert() function is trivial, too trivial for us and it is really annoying too. Better would be some sort of textfield where our debugging messages are displayed without disturbing the site interaction (alert() opens a popup and focuses it…). We’ll use a popup that can be closed without interupting the application and it won’t try to get the focus for every message.
debug: true,
console: null,
log: function(message){
if(!Engine.debug)
return;
if(!Engine.console){
// Log window does not exist, try to open it.
consoleWnd = window.open(‘’,‘Debug Information’,‘width=350,height=250,menubar=0,toolbar=1,status=0,scrollbars=1,resizable=1′); consoleWnd.document.writeln(‘
Engine.console = consoleWnd.document.body;
}
Engine.console.innerHTML += (message + "
n");
}
This makes it really easy to print debugging information on the running application: just use Engine.log(”Your message here…”); and Engine will take care of the rest. This is exactly what we need: the debugging information when needed but not always. This way of displaying debugging information is really simple, for more advanced features give Log4JS a try.
Modules design
Most AJAX applications in use right now load everything on startup, images, javascript and content. While this is surely an easy way to do things it’s not the best, because it takes a long time (sometimes too long) for the application to be ready, and much of the stuff that is loaded is never used, or used pretty late during execution. For exactly this reason we’ll divide the application into modules. Modules are independent parts of the application, like in our case these would be:
* Page: a simple module which will be implemented in this part of the tutorial. It will load an HTML file from the server and display it in the content area.
* Gallery: a gallery made of user pictures, the goal would also be to use Flickr as a backend for the pictures (e.g. take a group pool and display it, display pictures of a user, display pictures with a certain tag, …)
* News: simply an extension to the Page module this will allow administrators and moderators to post news. News are passed to the Javascript engine using XML. Its main purpose is to demonstrate how to use XML-Files.
* Messages: A module for sending and receiving private messages.
* Forum: the most complex module we’ll see during this tutorial.
First of all we’ll see how to load modules and register them into a module handler (the Engine) and then we’ll move on to actually design the modules.
Module handling
Basically the Engine does specify an API that the modules then may use to access the various parts of the Page, thus we create an abstraction layer between the actual interface and the application. Besides providing an easy to use interface to the Page, the Engine also takes care of loading and managing modules. First of all we’ll have know which modules have already been loaded and if they are not yet loaded we’ll have to load them upon request:
modules: array(),
registerModule: function(moduleName){
…
},
loadModule: function(moduleName, callback){
…
}
notice that we may provide a callback function so that will be executed as soon as the module is loaded. This is because we cannot use the following:
loadModule(“myModule”);
modules[“myModule”].execute();
because loadModule contains an asynchronous call which will immediately return. If we’re unlucky (and most likely we are) the second line is executed before the module has been downloaded and registered, thus generating some really nasty errors. The callback allows us to specify some actions that are to be executed when the module has been definitely loaded.
Modules can range from really easy ones, as the Page-Module is, to really complex things such as message boards, news system, live activity logs, to fully fledged Instant messaging application, there is absolutely no limit to the complexity. The only thing that we require is that the modules adhere to a certain format:
var moduleName = {
init: function(){
// Initialize the module
// Register the module Engine:
Engine.registerModule(moduleName);
},
// …
};
moduleName.init();
The last line is used to initialize the module. Since the module code will be eval()’d it must take care of registering itself to the module handler, the Engine.
The Page Module
The Page module is our first module. On execute it will get the static page via XHRequest from the Web server and display it in the content area. Being the simplest module it consists only of one function and one anonymous function, which will take care of loading the content into the content area. Don’t forget to re-apply the Bahaviours to the loaded code otherwise you might get some unexpected results.
So here it goes, without further ado the code of the Page-Module, by now you should be able to understand what it does.
var Page = {
init: function(){
Engine.log(“Page module loaded.”);
Engine.modules[‘Page’] = Page;
},
execute: function(url){
Engine.setStatus(“Loading content…”);
var myAjax = new Ajax.Request(“static” + url + “.html”,{
method: ‘get’,
// parameters: "?nocache=" + new Date(),
onFailure: function(){
Engine.showError(“Could not load content.”);
Engine.log(“Could not load page “ + url);
},
onSuccess: function(req){
Engine.log(“Loaded page “ + url);
Engine.setContent(req.responseText);
Engine.hideStatus();
}
});
}
};
Page.init();
The rest of the Engine
The engine still isn’t done by now, some functions from above are still missing but it is easy to guess what they do, we simply need some helper functions such as setContent, setStatus, showError and alike, so here goes the rest of the code:
setStatus: function(message){
if($(’status’) == null){
var body = document.getElementsByTagName(“body”)[0];
var div = document.createElement(“div”);
div.id = ’status’;
body.appendChild(div);
}
var node = $(’status’);
node.innerHTML = message;
new Effect.Appear(node);
},
hideStatus: function(){
new Effect.Fade($(’status’));
},
showError: function(message){
Engine.setStatus(message);
Engine.setTimeout(“Engine.hideStatus();”,15000);
},
setContent: function(content){
$(‘content’).innerHTML = content;
},
What’s next?
In the next part of this tutorial we will finally add some really new code that hasn’t yet been covered by my first tutorial, namely we will implement a signup form and some simple user management. For now take a look at the working copy of the application here, or download a snapshot of the code here.
Other resources
* Sergio Pereira’s really good introduction to Prototype
* My first AJAX tutorial
* Prototype Dissected: some really nice cheatsheets for prototype.js
Tools
* FireFox Venkman: the javascript debugger of FireFox (does not work with 1.5.0.1, but the guys over at GetAhead got a fix).
* FireBug Extension: FireBug is a new tool that aids with debugging Javascript, DHTML, and Ajax. It is like a combination of the Javascript Console, DOM Inspector, and a command line Javascript interpreter.
* Eclipse AJAX Toolkit Framework:AJAX Toolkit Framework (ATF) provides extensible tools for building IDEs for the many different AJAX (asynchronous JavaScript and XML) run-time environments (such as Dojo, Zimbra, etc.). This technology also contains features for developing, debugging, and testing AJAX applications. The framework provides enhanced JavaScript editing features such as edit-time syntax checking; an embedded Mozilla Web browser; an embedded DOM browser; and an embedded JavaScript debugger.
read more | digg story
No comments:
Post a Comment