I’m in week four of my Google Web Toolkit adventure and things are heating up nicely. I’ve already switched to IntelliJ and back to Eclipse at least once (not really counting the two times I switched in my head while I was laying in bed; let it not be said that being spoiled for choice is always a good thing).

Reason I’m currently sticking with Eclipse: it seems better suited for GWT development. As an editor, IntelliJ rocks for .NET/ReSharper developers. All the shortcuts are familiar and things seem more organized and intuitive. Generally speaking, Eclipse feels like an IDE developed by committee, which it kinda was from what I’ve read. But the GWT and Google AppEngine plug-ins for Eclipse are pretty solid and there’s no confusing terminology around libraries and facets and artifacts and modules like there is with IntelliJ. After all, I’m just a .NET developer.

The gwt-presenter library has been a godsend in the short time I’ve been on the project. Its implementation of MVP is cleaner than my kids’ hides after they’ve had a good whoopin’. Unlike the ASP.NET version of MVP I’ve used over the years, this one has a very decoupled link ‘twixt presenters and views. Communication is managed through dependency injection to wire up view interfaces to their implementations and through an event bus, which comes standard with the gwt-presenter libmockuprary.

Say you have a link in a left sidebar that users click to launch the Settings page in the main content window. With gwt-presenter, the workflow to wire this up is as follows:

  • In the left sidebar’s presenter, attach a click handler to the Settings link exposed as a method on the Display interface, which the view implements. (gwt-presenter appears to use a Passive View approach to MVP.)
  • In the click handler, raise a ShowSettingsWindow event on the event bus.
  • Elsewhere (for example, in the main AppPresenter), we register a handler on the event bus to listen for this event and swap out whatever is being displayed in the content window with the SettingsPresenter.

Here’s where it gets even better. I don’t even need to create a ShowSettingsWindow event. gwt-presenter has history management built-in. This means that in order to navigate to a new “place” in the app, all I need to do is raise a PlaceRequestEvent. Furthermore, I also don’t need to handle the event anywhere. The PlaceRequestEvent includes a parameter indicating the name of the place you want to navigate to. (I believe I’m simplifying but then, I’m a simple person.) As long as that’s mapped to the SettingsPresenter (typically, exposed as a property on the presenter itself), gwt-presenter handles all that for you including adding it to the browser’s history.

So to sum up, out of the box, gwt-presenter gives you:

  • A view and presenter decoupled thanks to dependency injection and a built-in event bus
  • navigation between views
  • browser history management and bookmarking

What makes this all the more amazing to me is something to which I alluded in the previous post: it’s nearly impossible not to use all of this in a GWT application. Yes, gwt-presenter is optional but it’s not optional the way ASP.NET MVC is optional to WebForms developers. The GWT documentation itself encourages the use of it as well as an event bus.

Note that I’m being sparse with implementation details. That’s because there’s no point. The absolute definitive guide for this is already underway over at Andreas Borglin’s pad. As much as I love David Chandler’s articles (and believe me, they’re golden), Andreas’s step-by-step guide to the various pieces, along with detailed source code for each step, is the type of teaching guide I can only aspire to. The purpose for this post is two-fold:

  • Get people over to Andreas’s site to join in the awesomeness
  • To help clarify my own thoughts on how this all works together.

As always, if any of this is helpful or interesting to you, that’s not my fault.

Kyle the Presented