Alex’s Notes

Alex’s Notes

Alex Reid  //  By day I'm a web-database systems developer. At all other times I'm a web geek, petrol head, anorak-level Beatles fan and father of one from Newcastle upon Tyne, UK.

All of the dubious opinions stated here are purely my own and not those of my employer.

Jun 24 / 4:42am

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. 

Loading mentions Retweet

7 comments

Jul 15, 2009
td said...
Hello Alex,

Thanks for the article. We are just getting our heads around implementing an event bus with GWT (despite the cloud of doubt you just brought over us with "GWT - it's not you, it's me"...). I would very much appreciate it if you could post an example of implementing an event bus using HandlerManager. I'm getting it... kind of... there are some ticklish points that will be sorted out by seeing a concrete example.

Thanks,
-Tom

Jul 15, 2009
Alex Reid said...
Tom,
Glad the article was useful. I should be able to post a very simple event bus example shortly.

As for casting doubt on your use of GWT - I think it depends on the demands and scale of the project. GWT is a great platform to develop in and definitely suits certain types of web app more than others. There's a lot about it I still really like.

Jul 15, 2009
td said...
Alex,

Well, that was fast. A thousand thanks for putting together the example. I was able to checkout the code and get it running in Eclipse. Seeing this code in operation has really helped me get a handle on setting up an event bus in our application. The "event bus" concept should prove helpful for what we're developing.

Thanks,
-Tom

Jul 15, 2009
Alex Reid said...
No worries, it was more a less a case of repurposing some code I already had.

I plan to post a JavaScript version of the same pattern for comparison.

Jul 24, 2009
Jonathan Jones said...
Thanks for you great & simple example. I was nearly there with CustomEvents but your EventBus class got me over the line. This approach is great for decoupling the objects.. really like it..
thanks again!!
Sep 23, 2009
Miguel said...
Hi Alex,
Your post was really great, I have one question though, is there any concern with memory leaks?, I saw your code, and I may be wrong but once you add the handler (the widget) and then dispose it (for example, repainting the page placing new widgets) the handler object may be preserved in the event bus (singleton) in the page forever and ever........, Could you clarify me this?
Best and thanks
Nov 25, 2009
Steve C said...
Alex,

Thanks for a clearer example than the others I have seen. One thing I wonder about, though, is the registration of handlers. Unless I missed something, it seems that the registration is solely by event type, rather than by event source.

For many custom events, there might be only one source, but for events that could be generated by multiple components, aren't all of them flowing through the same entire set of handlers, so that each handler would need to look at the event source to see if it actually wants to process the event?

Leave a comment...

 
Got an account with one of these? Login here, or just enter your comment below.
Posterous-login    twitter