Implementation of the MVC pattern

The implementation of the MVC pattern provided by pygtkmvc is a simplified version of the ``official'' pattern generally described by Software Engineering Theory ³.

Figure 2: Simplified Model-View-Controller Pattern

Simplification consists in the fact that in the more general pattern the Controller-View relationship allows a 1-N cardinality. Furthermore, the implementation is different as the view side cannot see the model part. The reasons behind this difference will be explained later, but we can anticipate here that this is due to the relationship between the view and the controller, that is stronger in pygtkmvc than in the classic MVC pattern.

Figure 2 shows three interconnected parts:

Model

Contains the state of the application. Also it provides support to access and modify the state, and knows how to handle dependencies between different parts in the state. For example the application logic could require that changing a variable, causes a changing of another. It is not required the model user to be aware about this dependency, because model autonomously handles it.

Zero, one or more Controllers can be connected to one Model (see Controller, below). Furthermore, one or more Views can be associated with parts of the state; for example a numerical variable could be visualized as a number, as well as a graphic bar. It is important to remark that a Model does not know that a set of Views is possibly connected to its state through a set of Controllers.

View

shows parts of the Model state, and interactively exchanges information with the User, via input/output devices. View also interacts with a Controller (see below), sending to it signals, and receiving information to visualize.

Furthermore, a View collects a set of widget trees built from a Glade file, and/or constructed by hand. Since a Widget contains a state, this implementation differs from the standard MVC pattern, where generally the View side is completely stateless.

A View does not know the semantics concerning what it visualizes, and neither knows that it is connected to a model.

Controller

Realizes the connection between Models and Views. A Controller contains the GUI logic: for example, it stores the information about what happens when a button is clicked (e.g. handlers of signal are located inside a Controller.)

A Controller perfectly knows the interfaces of the connected Model and View, and knows both the state and presentation (GUI) semantics. A Controller is associated to one Model (use a relationship), and in the current implementation is associated only to one View (has a relationship).

Two particular mechanisms make the isolation between Model and Controller, and between View and Controller. To support the former, the Observer pattern is provided (see 4.2), whereas latter mechanism is provided by the MVC pattern, and that is explained in 4.1.1.