This chapter will give a short introduction to the MVC pattern and the classes in the Tensegrity Graph Framework which participate in that pattern.
The principle concept in model-view programming is to maintain one model that holds shared data and multiple views that access this data. Such a scenario is encountered in graphics programs, where, for example, one window is rendered in black and white and another window is rendered in color. Both windows essentially show the same data. Moreover, changes in one window immediately trigger changes in the other window. This dynamic is referred to as a Model-Change-Event-Propagation and is a central mechanism in the model-view paradigm.
By associating many views with a single model, we obtain a 1 : n relationship between model and view objects. This divides the pattern players into two groups:
Model Objects associated with the model. These exist once per model and are shared across all views that are associated with the model.
View Objects associated with a view. These exist once per view and are independent of view objects in other views and in the model.
In a view context, the coordinate data of a visual representation of a node is usually view-dependent and thus part of the visual object. Connectivity information for a node, however, is a typical example of a model object.
The Tensegrity API implements the MVC pattern by supporting multiple views for a single
Graph model. The controller serves an administrative role
by notifying all VisualGraphView instances about any model changes
which have occurred. Normally, model changes lead to a situation where one or
more views might not reflect the current state of their model. The MVC pattern
decouples our Graph models from the views by having a
GraphController act as a mediator. This controller notifies
all views when the model changes and these views subsequently refresh themselves, if
necessary, by requesting data from their associated Graph model.
A graph model holds connectivity information and defines graphs
that are not visualized, thus allowing the framework to be used for non-visual
aspects of graph manipulation. In the Tensegrity Graph Framework, a graph model is defined by interface
Graph.
A graph view is associated with a single Graph model
with a n : 1 cardinality. The view part contains the
additional information that is required for a graph visualization, such as
coordinates, drawing styles and formats. The graph view functionality
is defined in interface VisualGraphView.
A graph controller is associated with a single
graph model with a 1 : 1 cardinality.
Controllers are classes of their own because sometimes you may need to use a
graph model without any attached views. In this case, a controller is not needed.
However, when using a Graph with one or more views, you are required to allocate
a GraphController that takes care of the update notifications for those views.
Now we will take a closer look at the interfaces and classes within the Tensegrity Graph Framework that are responsible for implementing the MVC pattern.
Table 1.1. Object naming
| Class | Package | Description |
|---|---|---|
Graph | graph.model | The model or "data" part of a graph. |
VisualGraphView | graph.view | The view or "visual" part of a graph. |
GraphController | graph.controller | Listener and notification component that mediates communication between graph and view objects. |
Many different views may be simultaneously associated with a particular Graph model.
Each view may also represent a filtered, overlapping perspective of that model, so it
is usually desirable to update all views whenever changes in a model occur. These
changes typically include the addition and deletion of nodes and edges as well as the
rerouting of edges. Basically, every change in the model might affect a view and trigger
the need for it to be visually refreshed.
In the Tensegrity Graph Framework, a model is never aware of any views that are associated with it. Views,
on the other hand, have a direct association with their model, from which they retrieve
and render relevant data. Listening for changes that occur and responding appropriately,
however, is not a responsibility of a view (they do not directly interact with the model
as event listeners). The mechanism which allows for this type of decoupled notification
is the event-listener implementation of a GraphController which propages model change
notifications to a view and view changes to a model.
Another responsibility of a GraphController is to attach and deattach views to and
from a model. Additionally, this component intercepts model events and propagates
changes to all of the views it controls. Application programmers should not
interact with the low-level event listener methods every time a view is attached
or deattached, however. This actitity is managed internally and automatically by
the various GraphController implementations of the Tensegrity Graph Framework.
Now that the general idea of the MVC paradigm is clear, we proceed to explain the implementation details of the corresponding classes within the Tensegrity Graph Framework. We start by disussing the model, continue with the view classes and finish by mentioning noteworthy details of the different controller implementations.
© 2004, 2005 Tensegrity Software GmbH