When creating an Application there is a need to employ a flexible framework for building the user interface. Modern GUIs provide a high degree of bandwidth for the end-user to interact with the application's domain object, but this increases complexity of the interface code. A framework helps ease this burden of complexity.
Dolphin makes use of a framework known as Model-View-Presenter or MVP. This is a component based architecture where components are created from a triad of interacting objects, models, views and presenters.
The recommended design steps for an MVP application or component are almost the exact reverse from those used when programming in other development systems such as Visual Basic where often it is the visible nature of the application that is created first. In MVP you are encouraged, first of all, to create the model classes that represent the domain layer in your application. Once these are, at least in part, operational they are followed by the presenter classes which handle the coordination between the user interface and the model. Only finally will you get around to creating the view layer which provides the actual graphical user interface. Obviously, because this is Smalltalk and such an interactive environment, you will iterate around this design loop several times before the final design is reached. The trick is to do just enough at each stage to allow your changes to be tested and the overall application incrementally pieced together.
So, to design an MVP component follow these steps:
Either choose an existing class to hold the model data or create a new one using the New Class pattern. Your model may eventually consist of a number of classes but there is usually an umbrella class which represents the model in its entirety. It is normal to subclass a model from class Model although this is not essential. The only real advantage to doing so, is that Model directly implements #setEvents and #getEvents to provide a more efficient event triggering mechanism. This is often useful since models must inevitably trigger events to communicate with their presenters and views.
Example A: Let's say you are creating a drawing/scribble component. The model will hold the data that represents a drawing. The drawing may consist of a number of primitive graphical operations such as line, rectangle, ellipse etc. Therefore you might create one or more classes to represent these operations and use a ListModel to hold the collection of operations that represent entire drawing.
Example B: Let's say you are creating a component to edit client details. The model will represent a client as an object and will hold information such as name, address, email etc. Therefore you will probably create a class (Client, say) descended from Model with instance variables for each of the attributes. In a simple design these instance variables will probably hold the attributes as Strings.
The next stage is to design the presenter which represents the heart of a user interface component. When doing this, bear in mind that you may eventually create several different presenters that work with the model you have just designed. The presenter (and its attached view) simply represent a method by which a user can interact with a domain model and, under different circumstances, you may wish to provide for different user interfaces.
Most MVP components can be re-used to build more complex composites and it is important to realize that the design process differs quite significantly depending on whether you are building a basic (elemental) component or a composite one. So, it is at this stage that you must decide whether the component is to be a Basic or Composite one. This is usually fairly apparent from the nature of the model. If you think that your model as a number of attributes, each of which can be represented by simpler components, then you are designing a composite. However, if the model data is effectively indivisible as far as the user interface is concerned then you are creating a basic component.
Example A. The interface for a drawing/scribble component can most likely be considered as basic rather than composite. The view will display a picture of the drawing in the model and the presenter will allow new graphic primitives to be added to this by interpreting user gestures with the mouse or menu commands.
Example B. The interface for a Client object will be a composite presenter. Each of the String attributes held by the model will be displayed (and possibly edited) by sub-presenters owned by the composite. Most likely you would use instances of TextPresenter for this job.
Once this decision has been made, follow the Basic MVP Component or Composite MVP Component pattern as appropriate.
The PersonalMoney tutorial is an example of an application built with Model-View-Presenter.
All of the Dolphin development system tools are built using the MVP framework