GWT 2.1 MVP Tutorial Part I: The model

Welcome to this tutorial on the new features of GWT 2.1.

Some time ago, the Overlook Team decided to use Google Web Toolkit to provide a browser-based interface to our great discovery engine for Fing. At the Google I/O 2010, new and very interesting developments have been presented for the 2.1 release. Things are being developed and changed in this very moment, and some time will be required until the design gets finalized and some documentation written.

If, like us, you are curious and impatient, we hope that this tutorial can give you a heads up to make an educated decision on the impact the new framework might have on your projects.

 Google I/O History

In 2009, Ray Ryan gave a speech at the Google I/O conference titled "Best Practices for Architecting GWT App". That speech outlined many key design factors a real world application should adopt, including Place Services and the Model-View-Presenter pattern.

While these patterns were outlined and packed in the 1-hour speech and, later on, in some documentation, no specific framework in GWT 2.0.x has been made available to assist developers in following that advices. A few open source projects implemented their own Places and MVP-based interactions, some like gwt-dispatch, gwt-presenter and gwt-platform defined their incarnation of such design principles.

In 2010, GWT presented in the speech "Architecting GWT apps". At the same time, GWT 2.1 M1 has been released, included the much awaited framework for Place Services and Model-View-Presenter user interfaces.

While Google is currently working on pinning the last details, the Overlook Team has dived into SVN to understand how the framework looks like. We'd like to share what we have learned with all of you.

Experimental API warning: As reported in GWT source code, these classes are still under rapid development, and are very likely to be deleted or at the very least modified. While I encourage to "try this at home", use it at your own risk in a production environment.
GWT 2.1 M2 has been frozen, so there is now a good chance that these parts are not changing anytime soon. But, you know, consider yourselves warned.

Dial 'M' for Model

interface EmployeeModel {
      String getName();
      void setName(String newName);
      void addListener(EmployeeModelListener l);
      void removeListener(EmployeeModelListener l);
}

interface EmployeeModel extends Serializable {
      String getName();
      void setName(String newName);
 }

Evolution in GWT 2.1

It is now the time to introduce the Model in GWT 2.1. The direction taken in 2.0.x has been pushed one step further, so that the Model is, in fact, only a Data Transfer Obejct (DTO). A DTO is an object whose main purpose is to be transferred, usually from one Tier to another Tier of a layered architecture such as Browser/Server/Database.

Let's now give a look at Value Store, the package that defines the Model/DTO programming interface.

If you are confused by the lingo, remember that Data Transfer Object is a design pattern. Value Object is now a less used term for roughly the same concept (many may argue that distinction, but this is a tutorial and I want to keep it focused on the code).
Valuestore is the management interface that performs CRUD (Create, Read, Update, Delete) operations on the Records, like Entity Manager in JPA and Persistence Manager in JDO.

The first interface to discuss is Record, the base interface to implement to define a DTO class. A Record holds data for a single instance of an entity. Let's suppose that in your server-side business model there's an entity called 'Employee' to represent a company employee list. 

To use it on the client side, you would need to define an EmployeeRecord class to hold the values of one of your employees, e.g. the employee name, birth date, etc.

A Record is able to provide values using Property objects as keys. The properties are type-aware, so that the employee name is a Property<String>, the employee birth data a Property<Date>, and so on. The following table reports these elements in a single example:

As you may notice, I've put two more Properties: id and version. These are default properties defined in the Record interface, and are used to uniquely identify an object through a unique id. Version (I suspect, we still have to verify) is used to keep track of changes to handle concurrent modifications of the same record.

The Record interface doesn't provide a generic reflection mechanism, so it's not possible to inspect a Record to know what kind of Properties it is made of. The current implementation RecordImpl, which delegates to JavaScriptObject implementation and provides JSON serialization, is actually holding a schema of the record properties in a RecordSchema object.

A model in MVP 2.1 would look like:

@DataTransferObject(overlook.server.domain.Employee.class)
public interface EmployeeRecord extends Record { 
 
    Property<String> name = new Property<String>("name", "Employee Name", String.class); 
    Property<Date> birthDate = new Property<Date>("birthDate", "Birth Date", Date.class); 
    String getName(); 
    Date getBirthDate(); 
}

Please note the annotation @DataTransferObject, that GWT uses to map the record to the equivalent server-side class. By declaring the connection, GWT is capable of binding automatically the interface properties with the JPA-annotated properties, thus greatly reducing the amount of boilerplate mapping work to be performed. This is going to be explained in detail in another part of the tutorial devoted to Request Factory.

Of course, when you add or modify a property in your real Model, appropriate changes must be applied to the equivalent Record. That's where the teamwork with Spring Roo comes handy: Spring Roo generates and keeps aligned a lot of these elements, and would reflect (overwrite) your EmployeeRecord java file every time you change your domain model definition.

A few details more

As a general rule, you are encouraged to define specific interface methods to extract data from you Record, e.g. getName() to get the Employee name. Record exposes also method to retrieve a value given a property. For instance, in a Renderer of a CellTree, when you are given an EmployeeRecord you should access its data through public getter methods.

The model-agnostic way that GWT uses to access a value is the Record.get(Property<V>) method. There's also a way to get not the value itself, but a PropertyReference<V>, which is just the property of a specific record, e.g. the Property 'name' of Record 'r2' in the example table above. In a few words, a property reference is just a value, which is exactly how Value<V> is defined. That is most useful to perform late bindings during RPC calls when the data is not yet available.

The DeltaValueStore is also worth mentioning a few words: as your model is now decomposed in Records and Properties, it is also possible to transfer only the data you need to. Hence the retrieval requests can dowload only a few properties of the Records. Furthermore, 'Update' operations can transmit back only the user changes (delta) instead of whole objects, which may give a nice performance boost.

What's next?

Now that we've laid the foundations, we should be ready to face the many intriguing features of GWT 2.1. The next tutorials are going to cover: 

• Request Factory to retrieve data asynchronously from the back end
• Places to represent application states
• Activities, Activity Mappers and Activity Managers to partition our work in self-contained mini apps.
• Cell-based components to display the data coming from our Records