A Quick Example of an Event-Plan Driven Application

[Alex]

I have posted the major part of this topic on my previous post of this forum under 'HTML & Web Site Design' category. Later I think this category is more better for the current topic. Enjoy and utilize the tit-bits from the masters of the art.

Let’s take a look at an example how all of this could work. As our application example we have an HTML document with two components: one to change the language, and another to change the layout. The application links DOM events (such as click events when the user clicks on links) to meaningful "interesting moments" in the application, moments that we encapsulate in Custom Events; for example, the user choosing to change the layout of the page is encapsulated in a Custom Event, and when that event is triggered we activate the scripts which perform layout modification.

All links here point to PHP scripts that would perform similar transformations on the server side to ensure that we are not dependent on JavaScript (for this example, however, we’ll look only at the client-side code).

eventPlanExample.html (excerpt):

<ul>
<li>Change Language:
<ul id="languages">
<li><a href="test.php?lang=en">English</a></li>
<li><a href="test.php?lang=de">Deutsch</a></li>
<li><a href="test.php?lang=nl">Neederlands</a></li>
</ul>
</li>
</ul>
<ul>
<li>Change Layout:
<ul id="layout">
<li><a href="test.php?layout=onecolumn">One Column</a></li>
<li><a href="test.php?layout=threecolumns">Three Columns</a></li>
</ul>
</li>
</ul>

Now for the important bit: we define an event plan with Custom Events and subscribe the necessary tool methods to each custom event:
customEvents.js:

// Changing the language
languageChange = new YAHOO.util.CustomEvent('language change');

languageChange.subscribe(retrieveData);
languageChange.subscribe(renderLayout);
languageChange.subscribe(ads);
languageChange.subscribe(pageWidgets);

// Changing the layout
layoutChange = new YAHOO.util.CustomEvent('layout change');

layoutChange.subscribe(renderLayout);
layoutChange.subscribe(ads);
layoutChange.subscribe(pageWidgets);

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.
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);

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.

The original article is divided into two parts. View the first part here:
Event-Driven Web Application Design

Christian Heilmann