About the Presenter model
This tutorial provides some additional detail about the Presenter model, and particularly about the purpose and behaviour of the Presentation Model and the Business Model.
The Presentation Model encapsulates ALL the behaviour of the GUI component. You must create one that extends the
caplin.presenter.PresentationModel abstract base class. You can then either instantiate your Presentation Model class directly, or just pass the class name to the Presenter Component in its constructor, and allow it to construct the model for you.
The Presentation Model handles component life-cycle events (i.e. events in which a change occurs to the focus, size, visibility or activity status of the frame containing the component) if it implements the
caplin.component.ComponentLifecycleEvents interface. Presenter forwards these events to the Presentation Model so that it can respond appropriately.
For example: the Presentation Model may dispose of resources that it no longer needs when its
onClose() method is called.
The Presentation Model is a logical representation of the user interface, and is composed of a number of properties and functions for manipulating these properties.
The Presenter library synchronises the value of these properties with the View. Note that the View depends on the Presentation Model and listens to it for changes to property values, but the Presentation Model is NOT dependent on the View. It must be possible to create an instance of the Presentation Model without the View being present, so that the Presentation Model can be unit-tested in isolation.
The Presentation Model contains the properties it needs to model the GUI component it represents. It detects changes to these properties, and can respond appropriately by setting the values of other properties.
The Presentation Model mustn’t contain any references to DOM elements in the View, as this breaks the Presentation Model pattern, by tying the Presentation model to a particular HTML construct.
If there is any complex business functionality, then it should be encapsulated in a separate "Domain Model" class. For example: Caplin provides a
caplin.trading.trademodel.Trade class, that encapsulates the code and workflow behaviours needed to execute trades via Liberator. It is the responsibility of the Presentation Model to instantiate any Domain model and synchronise it with the View.