Home » Java » Enterprise Java » GWT MVP made simple

About Joerg Viola

Joerg Viola

GWT MVP made simple

GWT Model-View-Presenter is a design pattern for large scale application development. Being derived from MVC, it divides between view and logic and helps to create well-structured, easily testable code. To help lazy developers like me, I investigate how to reduce the amount of classes and interfaces to write when using declarative UIs.

Classic MVP

You know how to post a link in facebook? – Recently I had to create a this functionality for a little GWT travelling app.

So you can enter a URL, which is then fetched and parsed. You can select one of the images from the page, review the text and finally store the link.
Now how to properly set this up in MVP? – First, you create an abstract interface resembling the view:

interface Display {
  HasValue<String> getUrl();
  void showResult();
  HasValue<String> getName();
  HasClickHandlers getPrevImage();
  HasClickHandlers getNextImage();
  void setImageUrl(String url);
  HasHTML getText();
  HasClickHandlers getSave();

It makes use of interfaces GWT components implement that give some access to their state and functionality. During tests you can easily implement this interface without referring to GWT internals. Also, view implementation may be changed without influence on deeper logic.
The implementation is straightforward, shown here with declarated UI fields:

class LinkView implements Display
  @UiField TextBox url;
  @UiField Label name;
  @UiField VerticalPanel result;
  @UiField Anchor prevImage;
  @UiField Anchor nextImage;
  @UiField Image image;
  @UiField HTML text;
  @UiField Button save;
  public HasValue<String> getUrl() {
    return url;
  public void showResult() {
  // ... and so on ...

The presenter then accesses the view using the interface, which by convention is written inside the presenter class:

class LinkPresenter
  interface Display {...};
  public LinkPresenter(final Display display) {
    display.getUrl().addValueChangeHandler(new ValueChangeHandler<String>() {
      public void onValueChange(ValueChangeEvent<String> event) {
        Page page = parseLink(display.getUrl().getValue());
        // ...
   // ... and so on ...

So here we are: Using MVP, you can structure your code very well and make it easily readable.

The simplification

The payoff is: Three types for each screen or component. Three files to change whenever the UI is re-defined. Not counted the ui.xml file for the view declaration. For a lazy man like me, these are too many. And if you take a look at the view implementation, it is obvious how to simplify this:
Use the view declaration (*.ui.xml) as the view and inject ui elements directly into the presenter:

class LinkPresenter
  @UiField HasValue<String> url;
  @UiField HasValue<String> name;
  @UiField VerticalPanel result;
  @UiField HasClickHandlers prevImage;
  @UiField HasClickHandlers nextImage;
  @UiField HasUrl image;
  @UiField HasHTML text;
  @UiField HasClickHandlers save;
  public LinkPresenter(final Display display) {
    url.addValueChangeHandler(new ValueChangeHandler<String>() {
      public void onValueChange(ValueChangeEvent<String> event) {
        Page page = parseLink(url.getValue());
        // ...
   // ... and so on ...

Since it is possible to declare the injected elements using their interfaces this presenter has a lot of the advantages of the full-fledged MVP presenter: You can test it by setting implementing components (see below) and you can change the views implementation easily.
But now, you have it all in one class and one view.ui.xml-file and you can apply structural changes much simpler.

Making UI elements abstract

TextBox implements HasValue<String>. This is simple. But what about properties of ui elements that are not accessible through interfaces? An example you may already have recognized is the VerticalPanel named result in the above code and its method setVisible(), which unfortunately is implemented in the UiObject base class. So no interface is available that could eg. be implemented at test time. For the sake of being able to switch view implementations, it would be better to inject a ComplexPanel, but even that cannot be instantiated at test time.

The only way out in this case is to create a new Interface, say

interface Visible {
  void setVisible(boolean visible);
  boolean isVisible();

and subclass interesting UI components, implementing the relevant interfaces:

package de.joergviola.gwt.tools;
class VisibleVerticalPanel 
       extends VerticalPanel 
       implements Visible {}

This seems to be tedious and sub-optimal. Nonetheless, is has to be done only per component and not per view as in the full-fledged MVP described above.
Wait – how to use self-made components in UiBuilder templates? – That is simple:

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
   <g:VerticalPanel width="100%">
    <g:TextBox styleName="big" ui:field="url" width="90%"/>
    <t:VisibleVerticalPanel ui:field="result"
                      visible="false"  width="100%">

Declaring handlers

The standard way of declaring (click-)handlers is very convinient:

 public void login(ClickEvent event) {
  srv.login(username.getValue(), password.getValue());

In the simplified MVP approach, this code would reside in the presenter. But the ClickEvent parameter is a View component and can eg. not be instantiated at runtime. On the other hand, it cannot be eliminated from the signature because UiBuilder requires an Event parameter.

So unfortunately one has to stick back to registering ClickHandlers manually (as one has to do in full MVP anyway):

public initWidget() {
       login.addClickHandler(new ClickHandler() {
               public void onClick(ClickEvent event) {
public void login(ClickEvent event) {
        srv.login(username.getValue(), password.getValue());

Making your app testable is one of the main goals when introducing MVP.
GwtTestCase is able to execute tests in the container environment but requires some startup-time. In TDD, it is desirable to have very fast-running tests that can be applied after every single change without loosing context.
So MVP is designed to be able to test all your code in a standard JVM. In standard MVP, you create implementations of the view interfaces. In this simplified approach, it is sufficient to create implementations on a component interface level like the following:

class Value<T> implements HasValue<T> {
  private T value;
  List<ValueChangeHandler<T>> handlers = 
                     new ArrayList<ValueChangeHandler<T>>();
  public HandlerRegistration addValueChangeHandler(
    ValueChangeHandler<T> handler) {
   return null;
  public void fireEvent(GwtEvent<?> event) {
   for (ValueChangeHandler<T> handler : handlers) {
    handler.onValueChange((ValueChangeEvent) event);
  public T getValue() {
   return value;
  public void setValue(T value) {
   this.value = value;
  public void setValue(T value, boolean fireEvents) {
   if (fireEvents)
    ValueChangeEvent.fire(this, value);

As usual, you have to inject this component into the presenter-under-test. Though in principle, you could create a setter for the component, I stick to the usual trick to make the component package-protected, put the test into the same package (but of course different project folder) as the presenter and set the component directly.

What do you win?

You get code structered as clean as in full MVP with much less classes and boilerplate code.
Some situations require utility classes for components and their interfaces, but as time goes by, you build an environment which is really easy to understand, test and extend.

I’m curious: Tell me your experiences!

Reference: GWT MVP made simple from our JCG partner Joerg Viola at the Joerg Viola blog.

(0 rating, 0 votes)
You need to be a registered member to rate this.
4 Comments Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy

Leave a Reply

4 Comment threads
0 Thread replies
Most reacted comment
Hottest comment thread
4 Comment authors
Mo_MAQThomas BroyershabermanSam Hough Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

newest oldest most voted
Notify of
Sam Hough
Sam Hough

It is a simplification but is it still MVP? My take on it would be that the view should hide more of its internals so generally it would be encapsulating the messy details of the UI. So this simplification would lose some of the benefits of MVP for more complex examples?


I agree with all of your points, and built Tessell as a result: http://www.tessell.org Specifically: * Having 3-types (display, presenter, view)–Tessell fixes by generating the display and view from the ui.xml file. You only maintain the ui.xml file and the presenter (and the test). * Characteristic interfaces (HasValue) not all widget methods–Tessell adds an interface for every GWT widget, e.g. TextBox has IsTextBox, so the display can expose “IsTextBox name()” and the presenter can use any of the methods it may/may not need. * Testing–just like your stub Value class, Tessell comes with stubs for all of the widgets, e.g.… Read more »

Thomas Broyer

If you moved to “part 2” MVP (in reference to http://code.google.com/webtoolkit/articles/mvp-architecture-2.html ) then you wouldn’t have felt MVP was so hard to write and test.

IMO, your approach is not wrong, but blurs the P and the V: when you have to show a field as having errors, how do you do it? you abstract the field behind an interface? would be much easier if you could simply write some addStyleName/removeStyleName in your view, if you had a clear separation between view and presenter at the Java level (of course, abstracting things is OK if the goal is reuse)


So that the same implementation as the GWTP framework, right?