Adding or removing tool methods here makes it very easy to extend the application by adding or removing functionality without having to change any of the methods themselves. We can also add and remove whole modules of component logic simply by commenting them out.

The tool methods used are stubs in this example, and all they do is report that they were activated:

pageMethods.js:

function retrieveData(type,args){
   log('retrieving Data for ' + args[0]);
};
function renderLayout(type,args){
   if(type==='layout change'){
     log('changing layout for ' + args[0]);
   } else {
     log('changing language layout for ' + args[0]);
   }
};
function ads(type,args){
   log('changing ads for ' + args[0]);
};
function pageWidgets(type,args){
   log('changing page widgets for ' + args[0]);
};
function log(msg){
   document.getElementById('output').innerHTML+='<p>'+msg+'</p>';
}

In the main JavaScript, we’ll apply the normal browser handlers to the components via Event Delegation, get the settings that should be applied from the links and fire the Custom Events. The important parts are in bold:

eventTriggers.js:

function initLanguages(){
   YAHOO.util.Event.addListener(this, "click", changeLanguage);
};
function initLayout(){
   YAHOO.util.Event.addListener(this, "click", changeLayout);
};
function changeLanguage(e){
   var t=YAHOO.util.Event.getTarget(e);
   if(t.nodeName.toLowerCase()==='a'){
     document.getElementById('output').innerHTML = '';
     var lang = t.href.replace(/.*?lang=/,”);
     languageChange.fire(lang);

}
   YAHOO.util.Event.preventDefault(e);
};
function changeLayout(e){
   var t=YAHOO.util.Event.getTarget(e);
   if(t.nodeName.toLowerCase()===’a'){
     document.getElementById(’output’).innerHTML = ”;
     var lang = t.href.replace(/.*?layout=/,”);
     layoutChange.fire(lang);
   }
   YAHOO.util.Event.preventDefault(e);
};
YAHOO.util.Event.onAvailable(’languages’, initLanguages);
YAHOO.util.Event.onAvailable(’layout’, initLayout);

You can download the demo or try it out for yourself.

The Key Differentiator and Where This Can Go

You could argue that the same functionality could be achieved without Custom Event handling (by having methods that encapsulate all subsidiary methods to be called for each event). The difference here is that we took the procedural nature of JavaScript out of the equation and we really link the interesting moments of the interaction to the relevant components of our application’s functionality in a single, centralized repository.

This also means that we can make a logging component subscribe to each of the events and store the current state of the whole application in a data repository, allowing for easily implemented "undo" functionality and storage of the application state, something that is a true pain to achieve without an underlying event plan.

Event-Driven Web Application Design as an Evolutionary Step

If the benefits of this approach are not obvious to you yet, think of the following: The evolution of web design happened mainly via separation of different layers.

• When we created the first web applications connection speeds were slow and being connected to the internet cost us money by the minute.
• Therefore we used frames to only load what has changed in the app. This led to the problem that if one frame didn’t load properly the app didn’t work and users were forced to reload the parent page.
• The next problem was that browsers didn’t support CSS and we used tables and font tags to define the look and feel which made it hard to change them and the documents themselves rather heavy.
• When CSS support became more consistent and usable, we were able to get rid of the extra HTML, documents got lighter and we could get rid of the frames again.
• The next problem we encountered was that mixing backend logic and HTML output was problematic for maintenance (maintainers needed both skills). As a result, we came up with templating languages that allowed for separation of server-side logic and the structure of the interface.
• Right now we still see the browser or the framework capabilities as the boundary of our applications. This is a pragmatic approach but limits us in our creativity and binds the application planning and documentation to browsers as the means of display.
• However, if we take events — including both DOM events and Custom Events — as the main consideration when planning the application we can free ourselves of these limitations and become a lot more independent of the technology in use.
• An application developed with an underlying Event Plan could be easily shifted to another technology like Flash or become a plug-in for thick clients like instant messengers or even operating systems.

The other big plus of starting an application with an event plan is that you cut the big application down into manageable chunks and components and you can plan the detailed usability, information architecture and accessibility for each component separately. This allows you to develop in parallel with the design or information architecture team and results in reusable components for other applications.

• Did You Get the Web 2.0 Memo?
• AJAX, RIA, Rich Web Technologies and iPhone Developer Summit Call for Papers Deadline January 25, 2008
• Where Are RIA Technologies Headed in 2008?
• Back to the Future with Cloud Computing