Custom events in web front-ends
As the browser becomes an increasingly more powerful deployment platform, many applications such as GMail consist of a single page that never refreshes. Code running on the client, commonly JavaScript, is responsible for manipulating the user interface, dealing with user interaction, communicating with servers and so on. Due to the shift away from the browser being a dumb terminal, tried and tested GUI design patterns can be applied to client-side code.
One useful pattern to consider is custom events and an event bus. GWT and many pure JavaScript libraries such as YUI and Prototype support this approach out of the box. This post will briefly discuss the approach taken with GWT.
The GWT HandlerManager provides a mechanism for objects to send (fire) or receive (handle) these events. Events within an application are higher level than DOM events such as onClick or onKeyPress; custom events are related to your application, i.e. StaffListLoadedEvent or StaffSelectedEvent.
Instead of passing in a collection of Staff objects directly to a user interface widget such as a data grid, we would set the widget to listen for onStaffListLoaded events.
We would then make the code responsible for fetching data from a server fire a StaffListLoadedEvent, when the data is available. There is no direct connection between the server communication class and the UI widget. No explicit binding of model to view needs to take place. The two components need know nothing about each other.
In a similar way to an exception being thrown, an event is fired by creating StaffListLoadedEvent object, adding data to it and calling the .fire() method. This event object can serve as an 'internal' data transfer object between the different parts of the application. In this example it holds the collection of Staff objects that we would have ordinarily passed directly to the UI.
This approach pays dividends when multiple widgets render the same data. For instance, an additional display widget could easily be added to the screen by also reacting to a StaffListLoaded event.
As well as reducing mundane and tedious plumbing code, this approach also makes unit testing possible as event objects themselves can be mocked.
None of the above is anything new. I am impressed, however, by the extent that this has streamlined the prototype application I am currently working on.
