Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

gwt-presenter, or “How to get excited about MVP”

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

This entry was posted in GWT. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    Wow, that’s actually a much better distinction than the one I was going to make. Thanks Robert. I may steal that explanation for future reference.

  • Robert

    Hey Manoj,

    GWT is a client side technology.

    MVC fits better on the server side where there are no real display smarts.

    The MVP pattern fits better for smart client approaches where you want to keep your business logic out of your views.

  • Manoj Waikar

    Hi Kyle,

    Isn’t MVC paradigm better than MVP specially for web apps? I know nothing about GWT etc. but Monorail convinced me of the popularity of RoR.

    Thanks,
    Manoj.