Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 The 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.

...