Canoo’s CTO Bruno Schäffer is speaking at SD West 08 on “Design Patterns for Rich Internet Applications”.
The following blog post outlines some of the concepts that he will cover in his talk. This is part four of a series of blog posts:
As we have seen in the previous posts of this blog post series, the presentation model clearly assigns responsibilities within the presentation layer. For simple user interfaces this approach is more than good enough. However, simple user interfaces are not really the domain of Rich Internet Applications (RIA). How can we tackle complex user interfaces using the presentation model approach? Let’s have a look at a non-trivial user interface:
It shows a typical master-detail view, further enhanced by a tree navigation on the left-hand side. The user can select different aspects of a person in the tree which brings up the corresponding form on the right hand side.
A naïve approach would be to create a single presentation model for the entire view. While implementing the presentation model you will soon realize that there is just too much state and behaviour to be captured in a single presentation model.
If a view is too complex, we have to split it up into manageable sub-views, each with a presentation model of its own. The combination of sub-view with its presentation model is called “application component”. An application component communicates with its environment only via the presentation model, i.e. the presentation model acts as an observer to other application components (resp. their presentation models).
A complex user interface can now be decomposed into a number of fairly independent application components. Independence means, that these application components can be employed or reused in different contexts. Independence is facilitated by relying on the observer pattern for communication with other application components.
How do you build a complex user interface from a set of application components. You simply arrange the application components in a hierarchy. Each application component is responsible for the creation of all directly known application components. Views and presentation models have to be aware of this hierarchy. An abstract base class for view resp. presentation model can factorize this.
The component hierarchy for our example user interface shown above looks like this:
Views are marked red and presentation models are blue.
As you can see not every view needs to come with a presentation model of its own. In this case the form view hooks up to the presentation model of the navigation view. A change in the tree selection will be broadcasted by the navigation presentation model. The form view updates itself accordingly by bringing the corresponding view to the front.
In addition, application components are perfect candidates for testing. Each application component can be tested independently (as described in part three). Testing a user interface made up from a hierarchy of application components can be considered as integration testing. It still focuses on the behaviour of the presentation models, though. An integration test case first creates the presentation model hierarchy and then tests the behaviour of the model hierarchy. The view code in this hierarchy is still trivial and therefore rarely need dedicated test cases.
Application components have another advantage. They are perfect candidates to be assigned as an independent task to a developer.
There are still some challenges left, such as clean initialization for presentation models and views when creating a hierarchy of application components or distribution of update events in this hierarchy without ending up in infinite update cycles.
In the next blog post, we will have a look at a simple framework which supports building user interfaces with application components. We will also see how easy it is to generically add undo/redo to an application.
Part 1: MVC and the Brave New World of RIA
Part 2: The World Needs More Models
Part 3: A Simple View on Complex Stuff
Part 4: Hierarchies
Part 5: Presentation Model Framework
Part 6: What’s Needed Besides the Presentation Model