...

• 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:
    • It is possible to create Views with zero business logic making it easier to test.
  • 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.