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?