Caplin Trader 4.5.2

Namespace: caplin/presenter


The Presenter library enables developers to create screen views using standard HTML templates, and then bind these to business logic that is defined within object-oriented JavaScript classes. This allows a separation of concerns, where UX/UI designers create HTML appropriately styled with CSS, which JavaScript developers are then responsible for enhancing with dynamic behaviour.

To achieve this separation of concerns, the Presenter library implements the Presentation Model pattern [Martin Fowler 2007] — sometimes also known as MVVM (Model View View Model).

2. The View

Presenter embeds the Knockout library for HTML to JavaScript binding. A simple example of a binding is as follows:

 <input type="text" name="firstName" data-bind="value:firstName"/>

This creates a two-way binding between the input element and a JavaScript property (firstName) contained within the presentation model. All view bindings are defined using similar data-bind attributes. The data- prefix is defined in the HTML5 specification to indicate a custom attribute that is valid HTML, but which is ignored by the browser.

Presenter enhances Knockout, allowing it to be embedded within Caplin web applications. It makes it easy to create standard Caplin components built using a presentation model and an HTML view (via caplin.presenter.component.PresenterComponent), and it makes it easy for these components to further embed any other Caplin components within themselves, or to make use of standard Caplin renderers for display purposes where this is useful.

Presenter also supports nested HTML templates which allows parts of views to be reused (avoiding repetition) and enhancing modularity.

3. The Presentation Model

The presentation model is a logical representation of a component's view on screen (the view). Everything on the screen is represented within the presentation model using properties. The presenter library binds these properties (instances of to the view. Assuming the binding is correct then the GUI is tested by unit testing the presentation model.

This is extremely important since it allows fast, reliable unit testing, enabling TDD. The alternative is to test via the GUI (using a tool like Selenium) which is much slower and results in fragile tests.