Graphical Editing Framework: Difference between revisions

Revision as of 12:15, 10 January 2008

Latest revision as of 17:20, 30 April 2025

(47 intermediate revisions by 30 users not shown)

Line 1:

{{CleanupMore citations needed|date=SeptemberJanuary 20072024}}

The '''Graphical Editing Framework''' '''(GEF)''' is a framework that was developed for thean [[Eclipse (software)|Eclipse]] platform.project Itthat isprovides knownframework asand aend-user frameworkcomponents withrelated ato verygraphical steepapplications.<ref>{{Cite learningweb curve,|last=Web but|first=Eclipse it|date=2013-01-31 offers|title=Eclipse someGraphical benefitsEditing Framework (GEF) |url=https://projects.eclipse.org/projects/tools.gef |access-date=2024-01-12 |website=projects.eclipse.org |language=en}}</ref>

== BenefitsHistory ==

GEF consists of the following components

GEF was initially developed as part of IBM's etools (<code>com.ibm.etools.gef</code>) and was contributed to [[Eclipse (software)|Eclipse]] in 2002 in version 2.0.0, consisting then of two components: Draw2d, a 2D visualization component based on the [[Standard Widget Toolkit|Standard Widget Toolkit (SWT)]] and GEF (MVC), a related model-view-controller framework that can be used to realize graphical editors as part of Eclipse Rich Client Platform (RCP) applications. The first release at Eclipse was GEF 2.1.0 in March 2003. The next major version, GEF 3.0.0, was released in June 2004, providing many new features like support for rules and guides. Zest was added as a third project component in 2007 in version 1.0.0 as part of the GEF 3.4.0 release. Since 2004, when GEF 3.0.0 was released, only compatible changes have been applied to the framework's [[API|application programming interface]] (API).

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

A new major revision of the framework has been developed in parallel to the maintenance of the GEF 3.x components by the project team since 2010. It is a complete redesign that is much more modular, uses JavaFX instead of SWT as underlying rendering framework, and can be used also independently of Eclipse RCP applications. Commonly referred to as GEF4, its components were initially released in version 0.1.0 (with still provisional API) in June 2015 as part of the GEF 3.10.0 (Mars) release. The GEF4 components are to be published in version 1.0.0 as part of the GEF 4.0.0 (Neon) release in June 2016.

== Benefits ==

* Having a Graphical Representation and being able to edit it

* Predefined Tools for Selection, Connection Creation and others.

* [[Model-view-controller]] (MVC) Concept

== MVCGEF Concept3.x ==

GEF 3.x provides framework technology to realize graphical editors and views as part of [[Eclipse (software)#Rich Client Platform|Eclipse Rich Client Platform (RCP)]] applications. It is internally decomposed into three components:

<u>Model:</u> The model has to be implemented by the user or it exists already in case of a legacy software.

* Draw2d – A 2D visualization component based on the [[Standard Widget Toolkit|Standard Widget Toolkit (SWT)]]

* GEF (MVC) - A model-view-controller component that can be used to realize graphical editors as part of Eclipse Rich Client Product (RCP) applications

* Zest - A graph-based visualization toolkit that can be used to realize views for visualization of graph-like data structures as part of Eclipse RCP applications

While graphical applications can be built on top of the GEF 3.x components directly, Draw2d and GEF (MVC) are also used by the [[Graphical Modeling Framework|Graphical Modeling Framework (GMF)]], which combines them with the [[Eclipse Modeling Framework|Eclipse Modeling Framework (EMF)]] to create the code for both the data model and the graphical editor.

<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().

=== Architecture ===

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

Editors created with GEF consists(MVC) 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

==== MappingDesign ofpattern GEF aspects to MVCusage ====

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

* GEF Model maps to Model of MVC, definition of model is left to user. This is the semantic model.

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

* GEF EditParts map to Controller of MVC, other controllers normally are: Graphical Editor in which model is shown, EditPolicies and user defined listeners/controllers.

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

* GEF Figures (created using Draw2d or other renderers) map to View aspect of MVC.

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

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

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

* [[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 and response mechanism ====

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.

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 inturnin turn returns ana "Command".

This is achieved using the [[Chain-of-responsibility pattern|Chainchain 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.

==References==

=== Request, Response in GEF ===

{{Reflist}}

''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 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 another 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.

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

* [https://github.com/eclipse/gef-classic GEF Source Repository]

* [http://www-128.ibm.com/developerworks/opensource/library/os-gef/ Create an eclipse-based application using the Graphical Editing Framework]

{{Eclipse Foundation}}

* [http://wiki.eclipse.org/index.php/Graphical_Editing_Framework GEF on Eclipsepedia]

* [http://gef.tigris.org/ A similar Graph Editing Framework at tigris.org]

[[Category:Graphics software]]

[[Category:Eclipse (software)]]