Page History

...

• Using definitions: the user interface should be as configurable as possible so that all three MVP elements would consume a definition (form, dialog or content view) and produce a UI component.
• Keeping views back-end-agnostic as much as possible: the business logic related to the back end, in most cases to JCR, should be replaceable with similar implementations for other back ends. This typically boils down to overriding a presenter.
• Reusability: we want to let the developers use the parts of our UI in various custom contexts and compositions.

...

The next section describes the shift in approach between Magnolia 5 and Magnolia 6.

...

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

...