Building an application in an unplanned way suffers many problems, such as adding new features, making a huge effort as the architecture becomes rigid, maintaining the software (activities such as bug fixing) can turn into a nightmare, white box testing or unit testing the code becomes very difficult, and conflict and integration issues when many people work with the same or similar features. Generally, if no thought is given to refactoring as you go, the architecture may become a big ball of mud, and without planning, you may end up with a poor structure that might become difficult to change. To overcome these issues, we can employ many design patterns, such as MVC and MVP. GWT development goes very well with the MVP pattern as it allows loose coupling and separation of concerns.
The MVP approach divides the code into layers that solve the issues with code. MVP believes in separation of concerns and proposes the following logical layers:
Switching between views is tied to the history management within the presentation layer.
The following figure represents the MVP components:
The presenter contains a view interface and a model. A concrete view is created and passed to the presenter; the presenter doesn't know about the concrete view, but it can access the methods of the view through the view interface. The view interface defines methods to render data, update the view, or access a DOM component of the view, but the interface should not return a low-level DOM component to the presenter. If a view contains a button, the interface should define a method to get hold of the button, but the method shouldn't return the button type; instead, it should return a high-level DOM component, such as clickable. The view doesn't handle the DOM events; the presenter implements the DOM event handling; for example, it will create a click event handler and set it to the button's handler list. That way, the view doesn't contain any logic. The presenter manages event handling and view transition. For example, consider a word processor application that has a view for listing all documents and has an edit button for editing a selected document. On the edit button, when you click on current (the list documents presenter), the presenter needs to change the view to the edit mode and open the document for editing. The list document presenter will fire an event so that another presenter can handle the edit operation. An edit document presenter will take care of the view. The presenter can update the model and send it to view for updating the view, such as a presenter making an asynchronous call to the server to get the updated stock price; on service callback, it will update the model with the latest data and call the view to update the new information.
The next section will demonstrate a GWT application and explain the MVP details.
3.15.186.79