A Shape Diagram Editor

Graphical Editing Framework (GEF) provides a powerful foundation for creating editors for visual editing of arbitrary models. Its effectiveness lies in a modular build, fitting use of design patterns, and decoupling of components that comprise a full, working editor. To a newcomer, the sheer number and variety of concepts and techniques present in GEF may feel intimidating. However, once learned and correctly used, they help to develop highly scalable and easy to maintain software. This article aims to provide a gentle yet comprehensive introduction to GEF. It describes a shape diagram editor - a small, fully functional test case of core concepts.
By Bo Majewski, Cisco Systems, Inc. December 8, 2004
Graphical Editing Framework (GEF) has been designed to allow editing of user data, generally referred to as the model, using graphical rather than textual format. It becomes an invaluable tool when dealing with entities that contain many-to-many, one-to-many and other complex relationships. With the popularity of the Eclipse Rich Client Platform, which leads to development of editors for more than just code, the importance of GEF is certain to increase. A few existing examples, such as database schema editor [7], logical circuits editor, and a task flow manager nicely illustrate both the power and flexibility of the framework that may be applied to such varied and disparate domains.
Yet the trouble with any generic framework, and GEF is no exception, is that its comprehensive design makes it hard to learn. Until recently, the smallest available example came with over 75 classes. Trying to understand nuances of GEF from interaction of that many user defined types and hundreds more native to GEF is certain to test the patience and acumen of even the most diligent developers. To rectify this issue, a new, much smaller example editor has been added and will appear in the upcoming 3.1 release. The shape diagram editor (see Figure 1) allows you to create and edit simple diagrams. It manipulates two types of objects, represented by rectangles and ellipses. You may connect any two objects with one of the two connection types. The two connection types are represented by solid and dashed lines. Each connection is directed, in the sense that it starts at a source object and terminates in the target object. The direction of each connection is indicated by an arrow. A connection may be reattached by dragging its source or target to a new object. Objects in the editor may be selected either by clicking on them or by dragging a rubber band around them. Selected objects can be deleted. All model manipulations, such as adding or deleting objects, moving them, resizing them, etc., may be undone or redone. Finally, the editor integrates with the Properties and Outline standard views of Eclipse. The editor's virtue comes not from its usefulness, but rather from the fact its limited number of user defined types serve as examples of a large percentage of concepts and techniques that one could encounter in a mature GEF editor.
Download and unzip the latest 3.1 GEF Examples from the GEF Project Downloads into your main Eclipse directory. To create a new diagram, launch the wizard by pressing Ctrl-N. Expand the Examples folder and select Shapes Diagram. The following sections give a detailed overview of the shape diagram inner workings. Before we dive into code, let us start with a big picture tour of the main GEF ideas.
GEF assists you in building a visual editor of your data. The data may be as simple as a thermostat with a single temperature knob, or as complex as a virtual private network with hundreds of routers, connections, and quality of service policies. To the credit of the GEF designers, they managed to create a framework that works with any data, or in GEF terminology, with any model. This is achieved by strictly following the Model-View-Controller pattern. The model is your data. To GEF, a model is any plain old Java object. The model should not know anything about either the controller or the view. The view is the visual representation of the model or one of its parts on the screen. It may be as simple as a rectangle, line or ellipse, or as complex as a nested logical circuit. Again, the view should remain ignorant about both the model and the controller. GEF uses Draw2D figures as views, although anything that implements the IFigure interface will do. The controller, known as an edit part, is the one that brings the two together. A top level controller is created when you start editing your model. If the model consists of many fragments, the top level controller informs GEF about that fact. In turn, child controllers for each fragment are created. If those again consists of subparts, the process is repeated until all objects that comprise a model have their controllers built. The other task of the controller is to create a figure representing the model. Once the model has been set on a particular controller, the GEF asks it for the congruous IFigure object. Since neither the model nor the view know about each other, it is the task of the controller to listen to changes in the model and update the visual representation of it. As a result, a common pattern in many GEF editors is a model that posts PropertyChangeEvent notifications. When an edit part receives an event notification it reacts appropriately by adjusting visual or structural representation of the model.
Another aspect of visual editing is reacting to user actions and mouse or keyboard events. The challenge here is to provide a mechanism that comes with sensible defaults, yet at the same time is flexible enough to allow those defaults to be replaced by interactions appropriate for the edited model. Take a mouse drag event as an example. If we were to assume every time a mouse drag event is detected that all selected objects are moved, we'd limit the freedom of the editor developer. It is quite likely that somebody might wish to provide zoom in