Graphical Editing Framework: Difference between revisions

Revision as of 09:19, 17 January 2011

Revision as of 22:17, 10 February 2011

Line 1:

{{Cleanup|date=September 2007}}

'''Graphical Editing Framework''' '''(GEF)''' is a framework that was developed for the [[Eclipse (software)|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 usesdata. 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 [[Model–View–ControllerGraphical Modeling Framework|MVCGraphical Modeling Framework (GMF)]] architecturalwhich stylecombines the [[Eclipse Modeling Framework|Eclipse Modeling Framework (EMF)]] and consistsGEF ofto create the code for both the data model and the followingdiagram components:editor.

Editors generated with GEF consist of the following components:

* A tool palette that provides editing capabilities to the user

* The diagram editor including tool palette

* Request/command objects that edit the model and provide [[undo]]-redo

* Figures which graphically represent the underlying data model elements

* A Draw2d subsystem that provides most of the default behaviours

* 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

* Request/commandCommand objects that edit the model and provide [[undo]]-redo

== Design Pattern Usage ==

Developers would use it to develop graphical editors that manipulate elements of their [[___domain model]] in ways that would be tedious to perform using scripts or form editors. In allowing the users to interact with, reposition, and reconnect the different onscreen elements, the GEF manipulates the underlying model immediately and provides them with a visual interpretation that better matches their understanding of the model.

GEF makes heavy use of [[design patterns|Design Patterns]]. These patterns are often mandatory under GEF and developers are required to understand them.

=== Model-View-Controller Pattern in GEF ===

== MVC Concept ==

[[Model-View-Controller]] is an architectural design pattern which divides an application into seperate parts which communicate which 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.

<u>* Model:</u> The data model hascan toeither be generated using EMF, self-implemented by the user or it existsmay 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 unterlying model.

<u>* View:</u> For each element within the model, including connections, a Viewfigure has to be implemented, using [[draw2d]]. In order to implement the view,Draw2d anframework. implementation of IFigure ofOftentimes the [[draw2d]]figure libraryis hassome to begeometrical useddrawing.

=== Other Featured Design Patterns ===

<u>Controller:</u> 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().

* [[Factory pattern|Factory]]: Creating models from palette, creating ''editparts''EditParts and creating figures.Figures

<u>View:</u> 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.

* [[Observer pattern|Observer]]: Typically a controller (read ''editpart''EditPart) listening on Model and View.

* [[Command pattern|Command]]: To implement Undo and Redo functions.

* [[Strategy pattern|Strategy]]: EditParts can install and remove EditPolicies dynamically

* [[Chain-of-responsibility pattern|Chain of Responsibilityresponsibility]]: To decide which ''EditPolicy'' should handle a ''Request''.

=== Request, Responseand inResponse GEFMechanism ===

=== Mapping of GEF aspects to MVC ===

* GEF Model maps to Model of MVC(Model View Controller), 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.

Any user action canwith bethe seeneditor ascan angenerate example ofa request. The nature of the request is understood by the context of invocation. ForThe thecontext discussion,is onedetermined canby safelythe say thatEditPart the "context"user isinteracts determinedwith byand the active "tool". ToolThe tool can be any selected entry in palette that is selected by user. We can say that, user using a tool, generates "Requests"palette. The request is handed over to the selected editpartEditPart, which in turn returns an "Command".

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.

This is achieved using the [[Chain-of-responsibility pattern|Chain of responsibility]] mechanism over Editpolicies,. theThe editpolicies determine if they can handle the request, elseotherwise 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).

=== 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.

=== 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 in turn returns an "Command".

This is achieved using [[Chain-of-responsibility pattern|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 [[Command pattern|Using Commands]], CommandStack holds references to commands that were previously executed. This helps in "undo", "redo" of commands.''

== 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 method pattern|Factory]], [[Chain-of-responsibility pattern|Chain of responsibility]], [[Command pattern|Command]], [[Observer pattern|Observer]] and [[State pattern|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.

* Command: To implement Undo and Redo functions.

* 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.

== 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.

==External links==