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() {
    result.setVisible(true);
  }
  // ... 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>() {
      @Override
      public void onValueChange(ValueChangeEvent<String> event) {
        Page page = parseLink(display.getUrl().getValue());
        display.getName().setValue(page.getTitle());
        // ...
        display.showResult();
      }
    });
   }
   // ... 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>() {
      @Override
      public void onValueChange(ValueChangeEvent<String> event) {
        Page page = parseLink(url.getValue());
        name.setValue(page.getTitle());
        // ...
        result.setVisible(true);
      }
    });
   }
   // ... 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'
xmlns:g="urn:import:com.google.gwt.user.client.ui"
xmlns:t="urn:import:de.joergviola.gwt.tools">
   <g:VerticalPanel width="100%">
    <g:TextBox styleName="big" ui:field="url" width="90%"/>
    <t:VisibleVerticalPanel ui:field="result"
                      visible="false"  width="100%">
    </t:VisibleVerticalPanel>
   </g:VerticalPanel>
</ui:UiBinder>

Declaring handlers

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

@UiHandler("login")
 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() {
               @Override
               public void onClick(ClickEvent event) {
                       login();
               }
       });
       ...
}
 
public void login(ClickEvent event) {
        srv.login(username.getValue(), password.getValue());
}

Testing
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>>();
 
  @Override
  public HandlerRegistration addValueChangeHandler(
    ValueChangeHandler<T> handler) {
   handlers.add(handler);
   return null;
  }
 
  @Override
  public void fireEvent(GwtEvent<?> event) {
   for (ValueChangeHandler<T> handler : handlers) {
    handler.onValueChange((ValueChangeEvent) event);
   }
  }
 
  @Override
  public T getValue() {
   return value;
  }
 
  @Override
  public void setValue(T value) {
   this.value = value;
  }
 
  @Override
  public void setValue(T value, boolean fireEvents) {
   if (fireEvents)
    ValueChangeEvent.fire(this, value);
   setValue(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.

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 two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

4 Responses to "GWT MVP made simple"

  1. Sam Hough says:

    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?

  2. shaberman says:

    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. StubTextBox, which has non-DOM/pure-JVM implementations of their behavior. It also automatically creates a stub view that implements the display interface but that you can use for testing.

    To me, Tessell made GWT MVP fun again–though I am of course biased. But try it out and let me know what you think.

  3. 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)

  4. Mo_MAQ says:

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

Leave a Reply


5 − = zero



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close