code

In these days I spent a lot of time to get a deeper knowledge about the Model View Presenter design pattern and at the end of the day I have to say “it rocks!”.
The Model View Presenter design pattern is a variation of the Model View Control that in a similar way separate the concerns of an application’s data, presentation and user input into specialized components.
The original implementation of the MVP is born in the 1979, its name was Thing Model View Editor and during these years there were a lot of different implementations between them the Taligent’s one (1996) was for sure the more sophisticated and the more powerful.

During the preparation of material on presentation layer patterns in 2006 Martin Fowler decided that the treatment given to the MVP pattern must be divided under the names Supervising Controller and Passive View.
In the first one the View delegate user events to the Controller which in turn interacts with the business logic of the application and the uses data binding techniques and the Observer Pattern to update itself when changes occur in the model.

Supervising Controller decomposes presentation functionality into two parts: a controller (often called presenter) and view. The domain data that needs to be displayed is separate, and following rough MVC terminology I’ll refer to it as a model, although it need not be a Domain Model.
In the second one the Controller is always the one that handle user input and that interact with the business logic but it’s also the responsible of the update of the view. In this way the view maintain no links with the Model and relies only on the controller for the all the presentation logic.
This pattern is yet another variation on model-view-controller and model-view-presenter. As with these the UI is split between a view that handles display and a controller that responds to user gestures. The significant change with Passive View is that the view is made completely passive and is no longer responsible for updating itself from the model. As a result, there is no dependencies in either direction between the view and the model.

These patterns are anther evolution of the MV* family, but came back again to the MVP and let’s try to see the building blocks of its implementation (I really want to point your attention on the building blocks words because in the future I want to show a Taligent like implementation of MVP in Flex) and on the wiring between the presenter and view.
In the sample implementation we’ll discover in this post we’ll take in exam a simple form used to recover the details of some customers stored in a simple XML file.
The View is responsible for visual representation of the UI and it contains a presenter in private field. View is implementing interface whose members are approximated and technology striped UI elements of the view. When some event occurs on view is just forwarding it to presenter and it is presenter responsibility to handle the event. Presenter is manipulating view by talking to interface representation of the view. Presenter should never reference directly view members (UI controls). Presenter for his logic operations is using Model which can be persisted state or representation of the object which provides necessary functionality.

In the application sample you find here there are a lot of actors: an MXML file that contains an instance of the UserView component that extends tha VBox class, the IUserView interface that defines the method the view needs to update its state, the UserViewPresenter class that is the responsible of the search operation and of the update of the view

The MXML fine that holds the application is self explanatory, it only defines the custom component view

<contactDetail:UserView x="10" y="10" />

The interface IUserView (implemented by the UserView.mxml file) define the methods we need in order to update the view and get the search criteria from the view to complete the operation

function set userName(value:String):void;
function set lastName(value:String):void;
function set city(value:String):void;
function set errorMessage(value:String):void;
function get searchCriteria():String;

The UserView custom component contains the MXML tag needed to define the UI (sorry for not using code behind but the focus of the post is different) and the call to the recoverData() method defined in the presenter

<mx:Label text="Contact Details Manager" width="100%" fontWeight="bold"/>
<mx:Label id="_errorMessage"  width="100%" color="#FF0006"/>
<mx:Form width="100%" height="50%">
<mx:FormItem label="Name" width="100%">
<mx:TextInput id="_userName" editable="false" width="100%"/>
</mx:FormItem>
<mx:FormItem label="Surname" width="100%">
<mx:TextInput id="_lastName" editable="false" width="100%"/>
</mx:FormItem>
<mx:FormItem label="City" width="100%">
<mx:TextInput id="_city" editable="false" width="100%"/>
</mx:FormItem>
</mx:Form>
<mx:HBox width="100%">
<mx:Label text="Insert a code to search" />
<mx:TextInput width="120" id="_searchCriteria" restrict="0-9" />
<mx:Button label="search" click="_presenter.recoverData()" />
</mx:HBox>

It also contains the methods defined in the IUserView and a private method that is registered as a listener for the creationComplete event that initialize the presenter

private function init():void{
_presenter = new UserViewPresenter(this);
}
public function set userName(value:String):void{
_userName.text = value;
}
public function set lastName(value:String):void{
_lastName.text = value;
}
public function set city(value:String):void{
_city.text = value;
}
public function get searchCriteria():String{
return _searchCriteria.text;
}
public function set errorMessage(value:String):void{
_errorMessage.text = value;
_errorMessage.visible = value != "";
}

As we already said the presenter is the one that handle with the business logic (in this Mickey Mouse sample we have simulated this with the XML data) and that update the view trough the interface without accessing directly the user interface elements.
In order to complete these tasks the presenter stores as a private member the view and perform the update accordingly to the result on the research on the XML file performed in the recoverData public method

public function recoverData():void{
if(_view.searchCriteria == ""){
_view.errorMessage = "Insert a code please!";
}else{
var data:XMLList = _xdata.customer.(@code == _view.searchCriteria);
if(data.length() == 0){
_view.errorMessage = "No user found!";
_view.userName = "";
_view.lastName = "";
_view.city = "";
}else{
_view.userName = data.firstName.text();
_view.lastName = data.lastName.text();
_view.city = data.city.text();
_view.errorMessage = "";
}
}

As you can see the MVP pattern it’s simple and powerful because it’s easy configurable in order to perform unit testing and because the presenter depends only on the view interface and not on the UI implementations. I really want to make a deeper post on the MVP in the next days discovering the the implementation of the Taligent’s one with Flex.