Event-Driven Web Application Design

[Alex]

Frontend engineering rocks right now. The era of boring web sites is over and we’re all into pushing the envelope, erasing boundaries and getting beyond whatever prevents us from building the next killer web application. New companies building quick-turnaround web products spring up like mushrooms and many an old convention of web design is cast aside to make way for quick prototyping and agile development.

The real confusing part of it — at least to me — is that we don’t try out new ways to approach web application development. Instead, there seem to be two separate schools of development approach:

You either use a framework (like Ruby on Rails, Spring or Microsoft .NET) to build your web-app or
You build your web app with best-practices ideas coming from more traditional web design and/or application design.
The framework approach relies heavily on the quality of the generated code and the accessibility and usability of the out-of-the-box page widgets and components. The pure web design approach relies on what HTML allows you to do and most of the time doesn’t take scripting-enhanced widgets into consideration.

As there are not many developers that follow both approaches there is a big divide in skill sets. People tend to become experts in one or another and stay within this comfort zone when talking to other developers. This is a real big waste as both factions could learn a lot from each other. All we need to overcome are the competing notions that (a) web standards and accessibility are show-stoppers for rapid framework-driven development and that (b) frameworks are a source of bad and invalid code. Both approaches are flexible: Frameworks can be extended to produce cleaner code and web standards can be seen as an agreed way of working with one another rather than as immutable laws that are never to be broken.

A Problem of Approach
The sad truth now is that both approaches often lead to hard-to-maintain products that don’t scale gracefully and are a pain to make accessible, localise to different languages or customise to different needs and channels. This is caused by false assumptions made by practitioners of both approaches:

The framework approach relies on a silver bullet and approaches web development with fat-client application ideals from higher programming languages like Java or C++. This does not take into consideration the fact that web development is a discipline that operates with great uncertainties regarding the nature of client-side hardware and software. Optimization has to be for the user and not for the developer (although these don’t necessarily have to be mutually exclusive).
The web standards approach would not be a problem at all if people would follow standards with the goal of making things easier by following an agreed approach and not see following the words of the W3C to the last detail as the only way to do things. Web standards are there to take the randomness out of web development and not to act as a policing tool.
The crux of the matter is that we don’t really yet understand how to build a real web application. We take tried and true methodologies that cover other development scenarios and try to shoe-horn them into something that helps us to achieve what we want on-time and within budget (and when was the last time that happened?).

The other problem is that we approach web application design with browser limitations in mind and plan only for what browsers can do rather than what the application should offer the user.

When it boils down to it, the main differentiator of a web application and a web site is that an app has much more interaction and is process-focused rather than content-driven. Users come in to achieve a goal: They provide data to the application, they use the application to enhance that data, and then they expect data to come out. They interact with components of the application and expect them to do something that brings them closer to their goal. It is of utmost importance that we plan for how users interact with the product and react accordingly.

When trying to accomplish this in the browser, there is one core technique at our disposal: Event handling.


Understanding Events
We must try to understand what an event is when it comes to user interaction through the duration of a user session.

Events as defined by the W3C are very complex and can be tough to understand. However, the most common way of thinking about events in JavaScript is:

Something happens to an element, to the main document, or to the browser window and that event triggers a reaction. For example, the window finishes loading and on that event we start an initialization method; or the user clicks a link and we use that event to trigger another function.
Most framework-generated code or even handcoded methods use this kind of event handling. We take the window, or a certain element and add handlers defining the event that should trigger a function. This leads to a rigid relationship between the markup and the functionality. As the interface of a web application might change (more links in a component, other buttons, more complex forms) this need to add more cruft begins to cripple our applications. It also means that maintenance must happen in two places — a change to our HTML means that our JavaScript needs to change, too.

The DOM Event Model however goes a bit further. It has a more granular definition of the workflow:

Something happens; an event occurs.
The investigation begins what element was activated and how. This happens by questioning each element from the window to the body to the first child node and so on until the element that was activated, the event target, is reached. This is called event capturing.
When the element is reached, the process of reporting goes back up through the DOM right back up to the window. This is called event bubbling.
You can intercept events on both legs of this journey at any time by adding event listeners to either the window or any of the objects that get queried. Event listeners define what event to look out for (click, keypress, load, mousedown…), the object to which the handler should be applied, and what method to call when it happens.
You can stop events from going back up to the window by calling a cancelEvent() method and you can retrieve the object the event occurred on, the event target, with a helper method called getTarget().
You can add as many listeners waiting for as many different events and each calling as many methods as you like.
Understanding and implementing this event model can free your application from the constraints of defined elements. For example, instead of applying an event listener for each link in a menu, you can assign a single listener to the menu item itself and retrieve the event target. That way you don’t need to change your script when the menu gets larger or when links get removed from it.

This is a very powerful and flexible approach often referred to as event delegation. Event delegation allows you to react to changes in the document while applying fewer event listeners. You can assign different handlers to different parts of your document (the menu, the main content, a sidebar, a language change menu) and define methods for each event (was it clicked? was a key pressed on it?). These methods then retrieve the element that was affected and react accordingly; for example, you can react differently for links versus buttons.

When using this idea (waiting for an event, investigating where it happens and acting accordingly) in web applications we mostly confine ourselves to what the browser reports us — the DOM events. This is not really necessary, and it’s a big limitation. Much that happens in an application — like a user switching between tabs in a TabView Control — could be thought of as an event and dealt with in the same manner.

Planning an Event-Driven Application
You can apply the same DOM-event style logic to anything that happens within your application itself. You can plan your application that way from the outset:

Application is loaded
Initialize the stage
Get the locale
Load extra content
Load adverts
Display stage
User changes language by activating a language component
Load extra content
Load adverts
Display Stage
The only thing that’s missing is turning this event plan (once it is finished for the first phase) into real code, and this is where the browser or JavaScript does not give us the built-in interfaces that we’d like to have for the purpose.

Beyond DOM Events: The Custom Event
Whenever the browser or JavaScript itself lets us down we turn to JavaScript libraries to solve the problem. In this case we’ll use the Yahoo! User Interface Library (YUI) with its Custom Event Object. This object allows you to define any event you like, subscribe listener methods to it, and fire the event whenever you want. It’s like simulating a click on a button. Internally, the YUI uses Custom Events a lot to trigger different reactions. For example the Animation utility allows not only for the animation of elements but makes it easy to create successive animations by providing onStart, onComplete and onTween Custom Events.

Using these events you can put together a web app that is easy to change, extend and maintain.

Follow the next post for more...

Christian Heilmann

[lovebeijgo]

The wolf has a winning game when the shepherds quarrel.-------------------------Our wow power leveling website offer Fast and Secure wow powerleveling service. WoW Power Leveling 60-70, Cheap wow power leveling 1-70. The Professional WoW Power Leveling! Powerlevel WoW Power Leveling now. WOrld of warcraft Power Leveling bloom of true love associated with this time of year!