2007
10.13

Like the Autonomous View, this is another one of Martin Fowler’s patterns. He calls it Supervising Controller, but suggests the alternative name of Supervising Presenter. I’m voting for the latter for the following reasons:

  • This pattern is a derivative of the Model-View-Presenter pattern rather than Model-View-Controller, so ‘Supervising Presenter’ seems a more suitable name.
  • Due to excessive overloading, the meaning of the term ‘controller’ in UI architecture discussions has become somewhat vague.
  • The ‘Presenter’ object is neither a controller in the J2EE / Model-2 / Cairngorm sense of the word, nor does it have much in common with the controllers from the original Smalltalk-MVC architecture.

Key features

  • State is in the view
  • Logic is in the Presenter
  • Presenter observes the view
  • Presenter updates the view
  • Presenter ‘knows’ about the view
  • View does not ‘know’ about the Presenter

Unlike the Autonomous View, the Supervising Presenter aims to extract non-trivial presentation logic out of the view into a separate class known as a Presenter. The view retains some autonomy, and controls in the view can still bind directly to underlying domain or value objects.

One very important feature of the Supervising Presenter pattern is that the view is unaware of its associated Presenter, but the Presenter is aware of the view. This is a trait inherited from Model-View-Presenter and is a principal difference between MVP and MVC. Each Supervising Presenter must observe its associated view for user events and coordinate the necessary view / model updates in response.

Motivations

Two reasons for adopting the Supervising Presenter pattern would be to address the drawbacks of the Autonomous View pattern:

Easier to test

Separating complex presentation logic into a separate class should facilitate unit testing. But there is one big fly in the ointment: The Supervising Presenter has a dependency on the associated view. So to test a Supervising Presenter you either need instances of your actual views, or ‘mock’ objects that simulate the behaviour of the views. If you use your actual view components, you’ll probably experience the same unit testing problems as you would with an Autonomous View

Improved separation of concerns

Following the Supervising Presenter pattern should yield an application-specific class hierarchy that is separated from the view classes, but coupled to them. Common presentation concerns can be refactored into Presenter base classes, and this should help to reduce code-duplication and improve consistency across an application.

Issues

How much logic do we extract?

The question of how much ’supervision’ a view needs is difficult to answer. The Supervising Presenter pattern exists half-way between Autonomous View (which we have already seen) and a pattern known as Passive View. The Passive View pattern extracts all logic from the view into a Presenter class, including bindings. For my own example, I have extracted any logic that cannot be expressed by a simple binding statement. I have also left the validators in the view, as they can be configured declaratively. But the lack of clarity on how much logic to extract may lead to inconsistencies on larger development projects.

Mock objects? What mock objects?

The use of mock objects is a common strategy when unit testing, but creating mock objects to simulate Flex views may not be a trivial task. Then again, once it is done the resulting mock-object library could be reused on other projects.

Logic is extracted but ’state’ remains in the view

The Supervising Presenter pattern extracts presentation logic from the view, but leaves presentation state in the view. A purist may argue that this is only a partial refactoring: In an OO architecture, state and associated logic are usually encapsulated within the same class. Dogma perhaps, but in my experience strong encapsulation does facilitate refactoring and reuse.

Example application

The example application demonstrates my take on the Supervising Presenter pattern. As with the Autonomous View demo, there’s additional information accessible via the View Source option.

Final thoughts

Despite the issues described above, I do think the Supervising Presenter deserves more attention. It holds the promise of improved unit test coverage, and may help to decrease code-duplication in an application. So far I haven’t encountered a Flex application that uses the Supervising Presenter pattern, so I guess my example must be the first. Perhaps you know different.

Up next: Presentation Model

6 comments so far

Add Your Comment
  1. Great series Paul! Looking forward to the rest.
    - Abey

  2. Looking at your example I noticed Presenters talking to Presenters eg in AlbumBrowserPresenter you have _albumFormPresenter.album = album;

    I’ve been using Cairngorm for a while and my usual solution would be for _albumFormPresenter.album to be binded to a model value and have AlbumBrowserPresenter.setViewTitle() dispatch a CairngormEvent rather than talk to another view directly in an attempt to keep all the logic MVC.

    Obviously there is no C in MVP but does this pattern still lend itself for use in Cairngorm application ?

    In your projects are you using Cairngorm ?

  3. Sorry that comment was supposed to be for the Passive View article

  4. Hi Bjorn,

    Yes, we use Cairngorm for all of our projects. I think the supervising presenter / passive view patterns do not gel particularly well with Cairngorm because they leave state in the view. Cairngorm applications usually place state in the ModelLocator or inside model / value objects. I’m not aware of any consulting projects that have used these patterns, and I’m not aware of anyone applying either of these patterns alongside Cairngorm. However, some of the comments posted here and on flexcoders do suggest use of these patterns in non-Cairngorm projects. Both patterns are also quite popular in the .NET community.

    Cheers,

    Paul

  5. Hi Paul,

    Thanks for this series, exactly what I need lately! One query I have with this particular pattern is where do you see the difference between state and logic and is state not dependent on logic?

    For example in your sample application what is the difference between the presenter doing:

    _albumFormView.cancel.enabled = canCancel();

    and the view doing:

    To me, both seem to be setting a ’state’ or value based on some basic logic. Only one is in the view, the other is in the presenter.

    Also, I recently saw Borre present the presentation model at 360Flex europe and it seems like a very nice approach. He mentioned it’s unlikely to become a part of Cairngorm because it can be so easily used with it, however an example of the presentation model in a cairngorm project would be very useful to cement the idea in :).

    Thanks Again,
    Dan

  6. It’s wild that today a year and a half after your post this is still one the best I know of on patterns in the Flex community. Personally this pattern looks like a slightly less aggressive PureMVC. Ironically I guess that would make their implementation pure MVP?