Summary
Web application developers follow either a framework-based approach, or an approach based on best-practices from Web standards and non-Web development practices, according to Christian Heilmann. In a recent article, Heilmann explains why both sides miss out on the benefits of a middle ground: An event-driven approach to Web application development.
Advertisement
Web application developers tend to fall into one of two categories, according Christian Heilmann, Yahoo UK's chief developer: those following frameworks, and those building apps based on best-practices from Web and other areas of application design.
In a recent article, Event-Driven Web Application Design, Heilmann points out that both camps lose by not considering a middle ground: A design framework that can be used both with Web application framework as well as in the context of a best-practices approach. That design framework, according to Heilmain, is event-driven application design:
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.
Heilmann suggests that you start thinking about the event chain of your application as a first design step, and outlines a simple process:
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.
The event-driven approach is especially useful considering that non-browser elements, such as third-party components, can also produce and listen for events, and hence fit into a single event-centric design plan.
The biggest benefit of the event-driven design, according to Heilmann, is that event listeners and handlers are independent of individual page components, and rely instead only on a page's DOM. Toolkits, such as the Yahoo YUI toolkit's event framework, makes adding and removing component-agnostic event listeners and handlers easy. In his article, Heilmann shows how a page could listen for, and handle, an event indicating that a user changed the page's language.
What do you think of Heilmann's event-driven approach?
Signal/event-driven programming is much closer to how systems in nature work. Most mechanisms in nature work by outputing signals and not by evaluating functions. Signal listeners attached to signal emitters take care of responding to changes, emitting signals themselves, and the whole chain of events makes up a 'computation'.
I have always been a supporter of the view that the best way to program is with signals/events. I have posted elsewhere an example of a phonebook application written in an imaginary language where any state change is an event/signal where listeners can be hooked:
(please ignore the rest of the rebelscience site - a bunch of unscientific claims at best)
The example is almost a complete application, very short, written in a few minutes, and if the language was real it would probably have worked in the first try.
Signal/event driven programming is suitable not only for web applications, but almost for any kind of application. Any computation can be viewed as an operation which emits one or more signals which are caught and processed accordingly. Foundamental operations like an addition have one signal, their result.
Another advantage with signals/events is that there need not be special support for exception handling, because exceptions themselves are signals. For example, a division has two signals: a 'result available' signal and a 'division by zero' signal. A file open operation again has two signals: a 'file opened' signal and a 'file open error' signal.
> Something happens; an event occurs.</li> > 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.</li>
If this is happening at the application level, it doesn't sound very event-driven to me. It sounds like polling.
The difference between an event driven vs a polling architecture is what initiates the response. What Christian and Frank are describing is a traversal of the DOM in response to the arrival of an asynchronous event, rather than the passing of some amount of time. The point of discussing the traversal algorithm is to note that you can attach the event at any point in the DOM structure, not just at the "leaf" node that actually is the primary target for the event handling.
Your comment about ASP.Net is apt, however the ASP framework is heavily prejudiced toward handling UI events on the server. This may or may not be a good thing depending on your point of view, I've found it to not be so great.
While I am happy to see the discussion (and the agreement) evenb here, outside my level of expertise, I'd like to make sure that I am not "Yahoo UK's chief developer" :-)
I am one of the 6 lead web developers in the web development team, and only at Y! since April.
> > The difference between an event driven vs a polling > architecture is what initiates the response. What > Christian and Frank are describing is a traversal of the > DOM in response to the arrival of an asynchronous event, > rather than the passing of some amount of time.
Perhaps polling isn't the best word to use but there's little difference between saying "questioning each element", and "polling each element". My point was that most event-driven systems don't require an investigation phase. The event and its handler are "wired" together and when the event occurs, the handler is invoked.
> Your comment about ASP.Net is apt, however the ASP > framework is heavily prejudiced toward handling UI events > on the server. This may or may not be a good thing > depending on your point of view, I've found it to not be > so great.
I think it would be more appropriate to say that MS has put more emphasis on server-side code in their description of ASP.Net, because it's really what differentiates ASP.Net from other web frameworks, but client-side scripts (and events) are supported as well.
> > > > The difference between an event driven vs a polling > > architecture is what initiates the response. What > > Christian and Frank are describing is a traversal of > the > > DOM in response to the arrival of an asynchronous > event, > > rather than the passing of some amount of time. > > Perhaps polling isn't the best word to use but there's > little difference between saying "questioning each > element", and "polling each element". My point was that > most event-driven systems don't require an investigation > phase. The event and its handler are "wired" together and > when the event occurs, the handler is invoked.
The main difference I see is that this querying is done when you know there's something to find.
But I agree it seems strange to have to do this. I would think you'd at least put which element the event is associated with in the event unless there's some technical reason why this can't be done.
> The main difference I see is that this querying is done > when you know there's something to find.
I guess it does meet the definition of event-driven since the processing is triggered by an event. It just doesn't have the characteristics you typically associate with an event-driven system.
> > The main difference I see is that this querying is done > > when you know there's something to find. > > I guess it does meet the definition of event-driven since > the processing is triggered by an event. It just doesn't > have the characteristics you typically associate with an > event-driven system.
Right, I generally think one of the benefits of event driven systems is that you don't have to look for things, they are 'handed' to you when something happens. When I look at the blog itself, I didn't really get the feeling that the event trapping algorithm was all that relevant to the developer but more of a technical description of a pretty ugly implementation. Maybe I missed the point, though.
Actually, I looked at the W3C spec and event-capture process has nothing to do with find which element was the event target. Event-capture and event-bubbling are optional ways to listen to an EventTarget. You can use event-bubbling without event-capture or neither. There is no search for the component. The event capture path is only followed against registered listeners. If the event capture stops propagation, it only affects those elements that registered listeners and descendants of the node that stopped the propagation.
Previous Topic
