Graphical Editing Framework
Graphical Editing Framework (GEF) is a framework that was developed for the Eclipse platform. It is used to create graphical editors for various diagrams like electrical networks or tree diagrams. Such diagrams offer easy editing capabilities for data in specific domains and are well suited as a graphical representation of that data. GEF editors can be used inside an Eclipse RCP application, the application framework offered by Eclipse. Usually, GEF is used as a part of the Graphical Modeling Framework (GMF) which combines the Eclipse Modeling Framework (EMF) and GEF to create the code for both the data model and the diagram editor.
Contents
Structure
Editors generated with GEF consist of the following components:
- The diagram editor including tool palette
- Figures which graphically represent the underlying data model elements
- EditParts which match figures and their respective model elements
- Request objects for user input
- EditPolicy objects which evaluate the requests and create appropriate command objects
- Command objects that edit the model and provide undo-redo
Design Pattern Usage
GEF makes heavy use of Design Patterns. These patterns are often mandatory under GEF and developers are required to understand them.
Model-View-Controller Pattern in GEF
Model-View-Controller is an architectural design pattern which divides an application into separate parts which communicate with each other in a specific way. The goal is to separate data model (model), graphical user interface (view) and business logic (controller). GEF uses the MVC pattern extensively.
- Model: The data model can either be generated using EMF, self-implemented by the user or it may already exist in case of a legacy software.
- Controller: The EditParts act as controllers. Typically, each model element has its matching EditPart. EditParts may contain other EditParts thereby matching model elements containing other model elements. EditParts also have a reference to the figure which graphically represents the model element. Finally, EditParts evaluate requests and create the appropriate command to edit the underlying model.
- View: For each element within the model, including connections, a figure has to be implemented using the Draw2d framework. Oftentimes the figure is some geometrical drawing.
Other Featured Design Patterns
- Factory: Creating models from palette, creating EditParts and creating Figures
- Observer: Typically a controller (EditPart) listening on Model and View
- Command: To implement Undo and Redo functions
- Strategy: EditParts can install and remove EditPolicies dynamically
- Chain of responsibility: To decide which EditPolicy should handle a Request
Request and Response Mechanism
Any user action with the editor can generate a request. The nature of the request is understood by the context of invocation. The context is determined by the EditPart the user interacts with and the active tool. The tool can be any selected entry in a tool palette. The request is handed over to the selected EditPart, which in turn returns a Command.
This is achieved using the Chain of responsibility mechanism over Editpolicies. The editpolicies determine if they can handle the request, otherwise they pass on to the next editpolicy. The order of declaration of editpolicies determine the order in which the request is passed around. The capable editpolicy creates a command. This command is handed back to the tool which initiated the "Request". Execution of the command causes the model to be modified (Response).
