Page History

This page describes some architectural approaches adopted for the UI framework in Magnolia 6.x, which—when compared to the UI framework used in Magnolia 5.7—constitutes a shift in the paradigm of applying the model-view-presenter (MVP) pattern. Below, we explain especially explain—especially to developers who write custom UI components in Java hJava—how Magnolia UI components utilize use the MVP development pattern for UI components.

...

• It is simpler to assemble UI components.
• Classes are preferred over interfaces.
• There are fewer abstractions and therefore have typically less code.
• There are fewer dependencies between parent and child components.

...

The

...

model-

...

view-

...

presenter (MVP) pattern

Understanding the MVP pattern

...

• The view primarily describes the layout of the UI and declares the handlers of the relevant user action events such as clicks, key presses and drag & drops.
• The presenter acts as a delegate of the view when executing the business logic of user events, for example, when interacting with the back end / DB or fetching the data that needs to be displayed in the view. Normally, each view would use its own presenter and would not show it to the outer outside world. In some cases, when the view is simple enough, no presenter may be needed at all.
• The model keeps the state of the view such as the current selection, the filters or toggles. Both the view and the presenter may have access to the model and may mutate it arbitrarily. However, when it comes to modifications done by the presenter, it is important to resolve synchronization of such view changes.

...

In the case of Magnolia, where flexibility is very important, MVP opens up possibilities to augment or customize the UI by overriding only one element of the triadthree elements.

MVP in the Magnolia UI framework

...

• Using definitions: the user interface should be as configurable as possible so that all three MVP triads elements would consume a definition (a 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.

...

We have moved the focus from the presenter to the view. When developing, you concentrate more on the view. When assembling components, you assemble views within the code of a view.

...

• Let it consume the definition.
• Build a view based on it.
• Produce child presenters, if any.
• Let Have these child presenters generate their views and attach them to the view. 

In this presenter-centric approach, the following can be observed:

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

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.

...

• Let the view consume the definition and populate itself from it.
• Let Have the view create and own the presenter as well as interact with it directly without additional interfaces.
• Compose the UI at the view level.
• Never let presenters interact with each other.
• Let the views manage the lifecycle of their children as well as create and destroy them deliberately.
• Have the views share configuration and resources among themselves without coding overhead.
• Assign each view its own component provider bound to the view's UI key.
• Associate each view with a storage space in an HTTP session where the view state can be kept.
• Provide convenient means for managing and sharing the view state (also known as view contexts).

Example:

WorkbenchView takes a definition, directly configures itself it and passes content view definitions to the content views. The content views take on to ContentView, which takes care of its own presenters. There is no need to involve the workbench in this. 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.

...