Graphical Editing Framework
From Wikipedia, the free encyclopedia
 |
This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. (September 2007) |
Graphical Editing Framework (GEF) is a framework that was developed for the Eclipse platform. It is known as a framework with a very steep learning curve, but it offers some benefits.
GEF consists of the following components
- draw2d has to be used for the View components
- Requests/Commands have to be used to edit the model
- Palette of Tools that are offered to the user
Contents |
[edit] Benefits
- Having a Graphical Representation and being able to edit it
- Predefined Tools for Selection, Connection Creation and others.
- Model-view-controller (MVC) Concept
[edit] MVC Concept
Model: The model has to be implemented by the user or it exists already in case of a legacy software.
Controller: The EditPart acts as a controller. Usually a GraphicalEditPart is chosen. For each model element, including connections, a specific EditPart has to be implemented. Listeners for the model have to be registered in the function EditPart.activate() and have to be unregistered within EditPart.deactivate(). If a model change is detected the view has to be updated accordingly. The EditPart knows both the model and the view. The view has to be created within .createFigure().
View: For each element within the model, including connections, a View has to be implemented, using draw2d. In order to implement the view, an implementation of IFigure of the draw2d library has to be used.
[edit] Mapping of GEF aspects to MVC
- GEF Model maps to Model of MVC, definition of model is left to user. This is the semantic model.
- GEF EditParts map to Controller of MVC, other controllers normally are: Graphical Editor in which model is shown, EditPolicies and user defined listeners/controllers.
- GEF Figures (created using Draw2d or other renderers) map to View aspect of MVC.
GEF recommends one-on-one mapping of M-V-C, though it is quite possible to have more than one controller (editPart) for the same model. In such an event there is an additional responsibility of keeping controllers and model in sync.
[edit] EditPolicies
The common behaviour across models is refactored into an editpolicy. There may be many behaviours for a given controller, so each "Editpolicy" is assigned to a "Role". This helps us understand the behaviour contributed by the editpolicy. Editpolicies can be installed and removed dynamically.
[edit] Request, Response in GEF
Authors' Note: For the following, knowledge of Design Patterns definitely helps.
Any user action can be seen as an example of request. The nature of request is understood by the context of invocation. For the discussion, one can safely say that the "context" is determined by the active "tool". Tool can be any entry in palette that is selected by user. We can say that, user using a tool, generates "Requests". The request is handed over to selected editpart, which inturn returns an "Command".
This is achieved using Chain of responsibility over Editpolicies, the editpolicies determine if they can handle the request, else 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).
One other mechanism to achieve the same is to create Requests programatically and hand them over to Editparts. The command generated can be subsequently executed on the "CommandStack". See Using Commands, CommandStack holds references to commands that were previously executed. This helps in "undo", "redo" of commands.
[edit] GEF Design patterns
In addition to MVC, GEF developers/enthusiasts need to have a good understanding of Design Patterns. The most recurring design patterns under GEF are Factory, Chain of responsibility, Command, Observer and State. These patterns are often mandatory under GEF, for instance EditPartFactory implementation. Certain aspects of GEF code can be correlated to these. The jargon (italicized text) is strictly GEF specific.
- Factory: Creating models from palette, creating editparts and creating figures.
- Observer: Typically a controller (read editpart) listening on Model and View.
- Chain of Responsibility: To decide which EditPolicy should handle a Request.
- State pattern: A typical example of which is opening editors for an input model .
Note that the usage of patterns is not restricted to those listed here.
[edit] GMF and EMF
GEF can be used directly with any model, including those built using the Eclipse Modeling Framework. The Graphical Modeling Framework provides additional infrastructure for diagrams which use or extend GMF's base EMF model.
