The term MVC is often used in conjunction with the architecture of user interface components, and stands for Model-View-Control, a design pattern that is explained in much more detail in [bib-GOF]. (A design pattern is simply "the core of the solution to a problem which occurs over and over again".)
In this document, the terms model and view are used in the sense of the MVC pattern. The term model is used when speaking of the graph's model, that is, when speaking of objects that implement the GraphModel interface. The term view is used in the context of the GraphLayoutCache object, and for objects that implement the CellView interface. In a sense, a cell may be seen as a model for the CellView, whereas the GraphModel is the model for the graph, and the GraphLayoutCache is the view for this model.
In general, a view never contains the data, and a model never contains painting code. This is also true in JGraph, with the exception that aside from the data that the model provides, the view may contain additional data, which is independent from the model.
The MVC pattern is a collaboration of design patterns, most importantly the Publish-Subscribe, or Observer pattern, which defines the relationship between the model and the view. In general, the Observer pattern is used to "define a one-to-many dependency between objects so that when one object changes state, all its dependent objects are notified and updated automatically" [bib-GOF].
One of the parameters of the Observer pattern is how to implement the notification scheme, that is, how much information should travel between the model and the view in order to describe a change. Basically, one solution computes the change information only once in the model, and dispatches it to all listeners, whereas the other solution simply notifies the listeners of a change, and the listeners in turn use the model to compute the change information if they are interested in handling the event.
Obviously, the first solution has the advantage that the change information is only computed once, whereas in the second solution, it is computed for every attached view. The disadvantage of the first approach is that a lot of information travels from the model to the view (possibly over a network), even if the view is not interested in handling the event. Of course, these solutions can be mixed as to compute part of the change information in the model, and the other part in the listeners. (JGraph uses the first approach, such that each event carries the full change information, which is also used to implement the command history.)
JTree extends JComponent, and has a reference to its TreeUI. JTree has a reference to a TreeModel and instantiates BasicTreeUI, which extends TreeUI, which in turn extends ComponentUI. The ComponentUI, sometimes called UI-delegate, is in a separate class hierarchy, so that it can be exchanged independently when the look and feel changes.
This basic structure of non-trivial Swing components is called the Swing MVC pattern. The control in Swing MVC is encapsulated in the UI-delegate, which is in charge of rendering the component in platform-specific manner, and mapping the events from the user interface to transactions that are executed on the model.
Since Swing offers the possibility to change the look and feel at run time, the component and its UI-delegate are implemented within different class hierarchies, such that the implementation of the UI-delegate can be exchanged at run-time, independently of the component. The JGraph component inherits this basic setup from the JComponent class and its UI-delegate, which implements the ComponentUI abstract class. (JGraph is in charge of instantiating the correct UI-delegate when the look and feel changes, and providing a reference to the current instance.)
In analogy to characters in Swing's text components, which do not change when the look and feel changes, JGraph's cells do not depend on the look and feel. However, the color scheme, keyboard bindings and other aspects of the system do depend on the look and feel and must reflect it. As in the case of text components, the split between platform-dependent and non-platform-dependent attributes is implemented using the concept of views, which are independent from the elements that appear in the model.
In Swing's text components, the elements of the model implement the Element interface, and for each of these elements, there exists exactly one view. These views, which implement the View interface, are either accessed through a mapping between the elements and the views, or through an entry point called root view, which is referenced from the text component's UI-delegate.
JGraph has an analogous setup, with the only difference that a graph view is referenced by the JGraph instance. The cells of the graph model implement the GraphCell interface, which is JGraph's analogy to the Element interface, and the cell views implement the CellView interface, in analogy to Swing's View interface. The cell views are accessed through the CellMapper mechanism, or through the graph view, which is an instance of the GraphLayoutCache class.
The GraphLayoutCache class can also be seen as a variation of JTree's default layout cache, because it separates the model from the view and provides view-dependent state-information for each cell, like the expanded property of a tree node, or one of its ancestors in JTree. However, since the GraphLayoutCache class works together with other classes, the analogy with Swing's text components is more helpful to understand the separation between the cell and the view; even if JGraph was devised from JTree's source code.
In contrast to text components, where the geometric attributes are stored in the model only, JGraph allows to store such attributes separately in each view, thus allowing a graph model to have multiple geometric configurations, namely one for each attached view. The GraphLayoutCache class can therefore be seen as a view-dependent geometric configuration of the model, which preserves state when the look and feel changes.
Serialization is the ability of an object to travel across a network, or to be written to persistent storage. Two different kinds of serialization are available: short-term serialization and long-term serialization. Short-term serialization is based on a binary format, whereas long-term serialization is based on XML, making the result human-readable.
The JGraph component supports short-term serialization, but long-term serialization, which is offered as of the 1.4 release of Java, is not yet implemented. Therefore, serialization should not be used to implement a storage format for an application. This is because the format may not be compatible with future releases of JGraph.
It is in general not sufficient to store the model alone, because part of the information, namely the geometric pattern of the graph, is stored in the view (unless the model is an attribute store). Thus, the views should be stored along with the model in order to store the graph with its geometry.
The ability to transfer data to other applications or the operating system by means of Drag-and-Drop or the clipboard is summarized under the term datatransfer. Drag-and-Drop allows transferring data using the mouse, whereas the clipboard provides an intermediate buffer to store and retrieve data using cut, copy and paste.
Between Java 1.3 and 1.4, the datatransfer functionality was extended with a high-level event listener, called TransferHandler. The TransferHandler is called from low-level listeners that are already installed in the JComponent class, and provides a set of methods that unify Drag-and-Drop and the clipboard functionality.
By inheriting from this class, the programmer can specify what data is transferred to the clipboard, or through Drag-and-Drop, and what happens after a successful drop on another target, or on the JGraph component, and how to handle non-standard contents of the clipboard.
Having said that, the concept of data flavors and transferables must briefly be outlined. Each object that is transferred to the clipboard implements the Transferable interface, which provides methods to retrieve the different forms in which the transferable is available to an application (for example as HTML or plain text). The Transferableitself can be seen as a wrapper that contains the different representations (MIME-types) of the transferable data, together with the methods to access these representations in a type-safe way.
JGraph provides an implementation of the Transferable interface in the form of the GraphTransferable class, which allows to transfer the current selection either as cells (serialized objects), as plain text, or as HTML. (Swing's default TransferHandler can't be used, because it transfers bean properties, and the graph's selection can't be implemented as a bean property.)
The GraphTransferable transfers the serialized cells along with their attributes, and a connection set and parent map that define the relations between the transferred cells in the originating model. These objects may be used as arguments in a target model's insert method, or individually, to provide a custom data flavor.
Graphs are made up of a number of classes and interfaces defined in their own package - the jgraph.graphpackage. The jgraph.graphpackage provides support classes that include the graph model, graph cells, graph cell editors, and renderers. The JGraph class represents the graph component, which is the only class residing in the topmost jgraphpackage.
The jgraph.eventpackage contains event classes and listener interfaces that are used to react to events fired by JGraph. The GraphUI class in the jgraph.plaf package extends Swing's ComponentUI class and defines abstract methods specific to graphs. The BasicGraphUI class in the jgraph.plaf.basic package defines default implementations for these methods.
In general, the graphical representation is look and feel dependent, which means that the graph reloads its user interface (UI) when the look and feel changes. The UI allows single-cell and marquee selection, as well as in-place editing, modification and moving of cells. Zoom, command history, Drag-and-Drop, and clipboard-support are also provided.
Cells have a user object. User objects are of type Objectand therefore provide a way to associate any object with a cell. Graphs have a fairly simple model, and each JGraph instance maintains a reference to a graph model. The key classes from the jgraph.graphpackage are listed in Table 2.
Table 2. Key classes from the jgraph.graph package
| DefaultGraphModel | A graph model that defines methods for adding, removing and changing cells. |
| GraphLayoutCache | An object that constitutes the geometric pattern of the graph. |
| DefaultGraphCell | The base class for all elements in the model, also represents a vertex. |
| DefaultEdge | An edge that may connect two vertices via a source and target port. |
| DefaultPort | Acts as a child of a vertex, and the connection point for edges. |
JGraph (see Section 2, “The JGraph Component”)
Event
GraphModelEvent (see Section 5.7.1, “Change Notification”)
GraphModelListener (see Section 5.7.1, “Change Notification”)
GraphSelectionEvent (see Section 5.7, “Event Model”)
GraphSelectionListener (see Section 5.7, “Event Model”)
Graph
AbstractCellView (see Section 4.4.2.1, “AbstractCellView”)
BasicMarqueeHandler (see Section 5.6, “Marquee Selection”)
DefaultGraphCell (see Section 3.2.2, “GraphCell Default Implementations”)
CellHandle (see Section 5.4.2, “CellHandle Interface”)
CellMapper (see Section 4.2, “Cell Mapper”)
CellView (see Section 4.4.1, “CellView Interface”)
CellViewFactory (see Section 4.3, “CellView Factory”)
CellViewRenderer (see Section 5.2.1, “CellViewRenderer Interface”)
ConnectionSet (see Section 3.4.2, “ConnectionSet”)
DefaultEdge (see Section 3.2.2, “GraphCell Default Implementations”)
DefaultGraphCellEditor (see Section 5.3, “Editors”)
DefaultGraphModel (see Section 3.3.2, “GraphModel Default Implementation”)
DefaultGraphSelectionModel (see Section 3.5, “Selection Model”)
DefaultPort (see Section 3.2.2, “GraphCell Default Implementations”)
DefaultRealEditor (see Section 5.3, “Editors”)
EdgeRenderer (see Section 5.2.2, “CellViewRenderer Default Implementations”)
EdgeView (see Section 4.4.2, “CellView Default Implementations”)
GraphCell (see Section 3.2.1, “GraphCell Interface Hierarchy”)
GraphCellEditor (see Section 5.3, “Editors”)
GraphConstants (see Section 2.5.1, “GraphConstants”)
GraphContext (see Section 4.6, “Graph Context”)
GraphModel (see Section 3.3.1, “GraphModel Interface”)
GraphSelectionModel (see Section 3.5, “Selection Model”)
GraphTransferable (see Section 5.5, “GraphTransferable”)
GraphUndoManager (see Section 5.7.4, “GraphUndoManager”)
GraphLayoutCache (see Section 4.1, “Graph Layout Cache”)
ParentMap (see Section 3.4.3, “ParentMap”)
PortRenderer (see Section 5.2.2, “CellViewRenderer Default Implementations”)
PortView (see Section 4.4.2, “CellView Default Implementations”)
VertexRenderer (see Section 5.2.2, “CellViewRenderer Default Implementations”)
VertexView (see Section 4.4.2, “CellView Default Implementations”)
Plaf
GraphUI (see Section 5.1.1, “GraphUI Interface”)
Basic
BasicGraphDropTargetListener (see [bib-Java1.4])
BasicGraphUI (see Section 5.1.2, “GraphUI Default Implementation”)
BasicTransferable (see [bib-Java1.4])
