Page History

...

• A presenter typically has a start(...) method with the definitions, the event bus and the initial state as input: 
  TreeView TreePresenter#start(workbenchDefinition, eventBus, viewTypeName, contentConnector)
  Besides being bulky and slightly confusing, these methods need to be called externally, forcing the lifecycle of a particular view/presenter to be managed outside. For example, a workbench has to call the start methods of TreePresenter and ListPresenter; otherwise, they would not be populated properly.
• A view typically interacts with a presenter over listener-like interfaces, which results in additional boilerplate code. In other words, after creating a view, a presenter would subscribe to view events as an observer.
• A parent presenter is aware of the sub-presenters. Moreover, it has access to the sub-views, which adds too much responsibility to it.
• Component composition takes place at the presenter level. This is counter-intuitive compared to composition happening at the view level since views are essentially synonymous with components.
• View state is managed by the presenter and is shared primarily via events, causing synchronization to be a problem—effectively, only notifications (messages) about the changes are sent, after which every part of the UI involved finds it difficult to store the current state.

Example:

WorkbenchPresenter is involved in the management of pretty much nearly all the other related parts. Among other things, the presenter:

• Creates sub-presenters.
• Feeds them configuration (definitions).
• Gathers sub-views and arranges them into one view (workbench viewWorkbenchView).
• Orchestrates the selection state.

...

WorkbenchView takes a definition, directly configures itself it and passes content view definitions on to ContentView, which takes care of its own presenters. The main reason why this separation is now possible is that, instead of manual state synchronization, we can do it through special tools based on session, scoping and IoC.

...