OBSOLETE

MVP Design

With the release of GWT 2.1, there are some classes and tools to aide with the development of a web application using the MVP (Model View Presenter) design pattern. The following link explains the MVP design pattern and the various ways the GWT framework helps implementing MVP based web application: http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html

Relationship between Presenter and View

There seems to be two basic approaches for how the Presenter and View interact with each other. We should pick one of the options and stick to it.

• Option A: There is a bi-directional relationship between the Presenter and the View (each has a reference to an interface of the other). In this case, the view listens to its own component events, and notifies the presenter when action needs to be taken, like adding a new message. Likewise the Presenter directly notifies the View when data changes occur.
  • Pros:
    • Easy to implement and read.
    • The presenter does not need to know anything about how the view meets it requirements, making it loosely coupled to the view implementation.
    • Works well with UiBinder, so the UI can be built with an XML configuration file, rather than code.
    • Very easy to have multiple implementation of the view (like a mobile view and browser view).

• • Cons:
    • It has bi-directional dependencies.

• Option B: The Presenter has a reference to the View, but the View knows nothing about the Presenter. With this option, the View provides hooks for the Presenter to listen the components in the View. The View does not listen to any components its own components.
  • Pros:
    • Dependencies go in only one direction.
  • Cons:
    • The Presenter must micro-manage the View, making the View interface very verbose.
    • The Presenter is tightly coupled to View implementation, making it difficult to create alternate View.

Server Communication

We have already established that we want the UI layer to communicate with the Sage Platform API via REST (HTTP). We have several options for how we make these calls. However, there are a few key points that need to be considered first before engaging in that discussion.

First, GWT code is divide into two parts, client and server. The client code is written in Java but gets compiled into JavaScript which runs within the client's browser. The server side code is written in Java and and gets deployed as a WAR in your favorite J2EE containers, such as Tomcat or GAE.

Since Client side code gets complied into JavaScript, the available libraries are extremely limited and only include the most basic Java libraries (minus most IO and JDBC) and GWT client libraries. On the other hand the server side code has no library limitations.

Second, client code can only communicate with server code through non-blocking asynchronous calls. The GWT client-side librareis support two types of asynchronous calls:

• Generic HTTP requests using the GWT RequestBuilder
• Custom RPC calls.

Both approaches have their limitations and implications that are worth considering.