GWT widgets vs MVP

Question

I'm looking for guidance on GWT architecture - when to use self-contained widgets vs MVP/Activities/Places.

Background

Having read the Google docs & scoured Stackoverflow, the gwt-examples project provides the best illustration to this question: http://code.google.com/p/gwt-examples/source/browse/trunk_2012/DemoGwtEditor/src/com/gonevertical/client/?r=3138#client%2Fviews

An application is divided into strongly de-coupled views, each view corresponding to a DOM peer. Activities & places are used to manage logic/RPC & navigation for a given view. Although imprecise, I'll refer to this pattern as MVP for brevity.

Widgets don't conform to this pattern, containing both view and logic/RPC calls.

Context

For the context of this question, I'm thinking of a complex GWT app using a TabLayoutPanel to create separate "screens". Each tab/screen relates broadly to a user activity. Mint.com is a good example of this kind of interface: a dashboard tab, a transactions tab, budgets tab, trends tab, etc. Each tab is built from a number of sub-components: a chart with selectors, a report-selector, a transactions-table, etc.

A sub-component like a transactions table is likely a composite of several GWT natives - e.g. a table with a couple of buttons. Google doco shows this sort of sub-component as being de-composed into MVP.

Assumptions - Widgets vs MVP

Treating the sub-components with MVP means either:

• very large view & activity/presenter classes for each tab or
• nesting MVP & an explosion of files (5 per sub-component)

On the other hand, sub-components as widgets means:

• very light MVP structure just to manage navigation history across tabs; hardly worth it
• no de-coupling (so difficulty with unit testing & switching out views)

Questions

• Are these assumptions correct?
• When to use custom, composite widgets over de-coupled views/MVP (or vice-versa)?

Answer 1

To answer this question you first have to look at activities and places - as activities are very often double duty as presenters. An activity manager takes care of a certain area of the screen. For example, the tabbed area could be controlled by an activity manager, where each activity was a different tab. This would indicate that each tab has it's own presenter. The presenter only needs to know about the view UI parts that it either needs to load data into/out of (and if only editing data you can reduce that to just the editor driver) and the items it needs to respond to on events.
The presenter doesn't need to know about view events that only have to do with the view responding, such as disclosure panels or things getting selected. The only time the presenter gets involved is when the UI sends an event that requires a bit of business/model logic - such as displaying more details on a list item, creating new list items, or saving the model.

Does that help?

Answer 2

Custom widgets and MVP are not comparable. They are not the answer options to one question, but are answers to 2 separate questions.

Question 1: When should I write custom widgets?? Question 2: Should I use MVP (or should I use MVC or should I not use any pattern)?

Answering the Question 2 first:

Use MVP

• For an application that will have several screens/activities that you feel can become cumbersome to manage if the code structure is too basic - ui, server commands, ui event handling etc in the same place
• When you know that you are going to have more than one UI for the same functionality. For eg, an application that will be used on a desktop browser as well as on a mobile browser. You can have entirely different "view" implementations for a desktop and mobile
• When you wish to do unit testing or test-driven-development
• If (you or your team) has experience working with frameworks such as MVC or MVP

Use Custom widgets

• When you dont have a widget that serves the purpose
• When you are using more than one widget to achieve some functionality. For eg if you want a text field, the user types in that field and you process the input at client-side, and show it in a label. Now lets say you want this functionality at more than one place. It would be wise to write re-usable code. Custom widgets does that
• When you want to enhance the functionality of an already available widget. For eg you want the default click handler for a button to handle in a certain way

Answer 3

The distinction between widgets and MVP is not as clear as you might think.
You can very well implement widgets using the MVP pattern.

An example for this are GWT's own CellWidgets.
CellWidgets like CellTableare internally using presenters and views to decouple view from logic/state. This makes it easy to unit test them.

I think there is no perfect solution and it probably also depends on the use-case/application. I usually try to avoid making backend calls (RPC or so) from widgets itself. I try to design widgets in a way, that the data they process and ultimately display is set from outside by the presenters.
So basically widgets are only view like sub-components which are populated and controlled by the presenter and are embedded in the view.

If you want to have more complex widgets which also contain business logic and backend calls then try to apply the MVP pattern to the widget.

It also depends on what kind of MVP framework you are using. With Activities and Places (ok, strictly not an MVP framework) you usually don't have nested presenters (see Thomas Broyer blog).
This is different when you use the GWTP MVP framework which has the concept of PresenterWidgets and allows to nest presenters.