[Eclipse] Getting Started series of GEF (2. GEF overview)

As mentioned in the previous post, GEF (Graphical Editor framework) is a graphical editing framework that allows developers to display and edit models in a graphical manner to improve user experience. Such an applicationProgramThere are many such tools as UML class Graph Editor, graphical XML editor, interface design tools, and Graphical Database structure design tools. To sum up, we can find that they share the following features in graphical Editing:

• Provides an editing area and a toolbar. You can select a required tool in the toolbar and place the node or connection in the editing area by dragging or clicking;
• A node can contain subnodes;
• You can view and modify most of the attributes of a node or connection;
• The connection endpoint is anchored on the node;
• Provides context menus and keyboard commands;
• Provides the zoom function for graphics;
• Provides an outline view that displays thumbnails of the editing area or tree structure;
• Supports the Undo/Redo function;
• And so on.

 
Figure 1 working interface of the GEF-based visual editor (VE)

GEF was originally an internal Eclipse project and gradually changed to an open-source eclipse tool project. Many other eclipse sub-projects require its support. Eclipse 3.0 has made great efforts to strip various functional components from platform, many tools, including GEF and IDE, can only be used within eclipse to become software/plug-in packages that can be used independently. In theory, we can use the GEF package from eclipse to construct our own applications. However, due to the natural connection between them, eclipse is indeed a well-supported development platform, so I recommend that you use it in eclipse.

The advantage of GEF is that it provides a standard MVC (Model-View-Control) structure. developers can use GEF to complete the above functions without re-designing themselves. Compared with other MVC editing frameworks, a major design goal of GEF is to minimize dependencies between models and views. The advantage is that you can select any combination of models and views as needed, it does not have to be limited by the development framework (but it is still rarely implemented out of draw2d ).

Now let's take a look at how GEF implements the MVC framework. In this post, we will give a brief introduction to its various components, and I will give a more detailed description based on examples.

Figure 2 GEF structure

Model: The GEF model only deals with controllers, but does not know anything about views. To let the Controller know the changes in the model, the Controller should be registered as the event listener in the model. When the model changes, the corresponding event is triggered to the Controller, the latter is responsible for notifying each view to update.

A typical model object contains a member variable of the propertychangesupport type, which is used to maintain the listener Member, that is, the Controller. For a model with a connection relationship with other objects, you must maintain a list of connected/connected connections; if the nodes corresponding to the model have the size and location information, maintain them. These variables are not necessary information of the model itself. Maintain them to make the model unclear, but you can construct some abstract model classes (for example, inherit all connected Model objects from node classes) to maintain their readability.

Relatively speaking, the model in GEF is the simplest part of MVC.

Controller: We know that the controller in the MVC structure is the bridge between the model and the view, and is also the core of the entire GEF. It not only monitors changes in the model, but also reflects the editing result to the model when the user edits the view. For example, when you delete a table in the database structure diagram, the Controller should delete the table object, Field object in the table, and all connections related to these objects from the model. Of course, in GEF, these operations are not completed by the direct controller. This will be discussed later.

The Controller in GEF is a so-called editpart object. More specifically, a group of editpart objects constitute the GEF controller. Each model object corresponds to an editpart object. Your application requires an editpartfactory object to create an editpart object based on the given model object. This factory class will be used by the view.

Rooteditpart is a special editpart that has nothing to do with your model. It serves to include editpartviewer and contents (the top editpart of an application, which generally represents a canvas) you can think of it as a contents container. Editpartviewer has a method setrooteditpart () that is used to specify the view's corresponding rooeditpart.

Figure 3 editpart object

Users' editing operations are converted into a series of requests, which have many types of requests. These types are called roles in GEF ), GEF includes graphical and non-graphical roles. The former includes layout role and layout-related operations, and the latter includes connection role and connection-related operations. The concept of role is implemented by editing policy. The main function of editpolicy is to create the corresponding command according to the request, and the latter will directly operate the model object. For each editpart, you can "Install" Some editpolicies. user-specific operations on this editpart will be handed over to the installed editpolicy for processing. The direct advantage of doing so is that some repeated operations can be shared between different editparts.

The gef sdk provides a detailed list of editpolicy, role, and request types in the help document (GEF Development Guide.

View: As mentioned above, there are many GEF views. GEF currently provides graphicalviewer and treeviewer. The former uses draw2d graphics (ifigure) as its representation, it is mostly used for editing areas, while the latter is mostly used for outline display. View tasks are equally heavy. In addition to the model display function, you must also provide the editing function, echo (feedback), tooltip, and so on.

GEF uses editpartviewer as the view. Its function is very similar to that of viewer in jface, while editpart is equivalent to its contentprovider and labelprovider, which are specified through the setcontents () method. The editor we often use is a graphicaleditorwithpalette (the editor provided by GEF is a subclass of editorpart and has a graphical editing area and a toolbar). This editor uses graphicaleditviewer and paletteviewer, paletteviewer is also a subclass of graphicaleditviewer. Developers need to customize editpartviewer in configuregraphicalviewer () and initializegraphicalviewer () methods, including specifying its contents and editpartfactory.

Editpartviewer is also an iselectionprovider, so that when you select an operation in the editing area, the registered selectionchangelistener will receive the selection event. Editpartviewer maintains the selected status of each editpart. If no selected editpart is selected, it is selected as the editpart of contents by default.

We have a preliminary understanding of the MVC implementation method of GEF. Let's take a look at what a typical GEF application looks like. Most GEF applications are implemented as Eclipse editors, that is, the entire editing area is placed in one editor. Therefore, a typical GEF application has a graphic editing area that is included in an Editor (such as graphicaleditorwithpalette). It may have an outline view and an attribute page, and an editpartfactory used to create an editpart instance, some model objects that represent the business, some editparts corresponding to the model object, each editpart corresponds to an ifigure subclass object displayed to the user, some editpolicy objects, and some command objects.

The GEF application works as follows: editpartviewer accepts user operations, such as node selection, addition, or deletion. Each node corresponds to an editpart object, this object has a group of editpolicies separated by role. Each editpolicy corresponds to some command objects, and the command directly modifies the model. User operations are converted to requests and assigned to the appropriate editpolicy. The latter creates an appropriate command to modify the model, these commands are retained in the Command Stack of editdomain (an object specifically used to maintain editpartviewer, command, and other information. Generally, each editor corresponds to a unique object) for Undo/redo.

The above introduces some important concepts in GEF. I don't know if you have a rough impression on it after reading it. It doesn't matter if it doesn't exist, because there will be examples in the post below. The example we use is the sixth project mentioned in the preface.

References:

• GEF Development Guide
• Eclipse development-using the graphical editing framework and the eclipse modeling framework