In the previous post already mentioned that Gef (Graphical Editor Framework is a graphical editing framework that allows developers to show and edit models in graphical ways to enhance the user experience. Such applications have a lot, such as: UML class diagram editor, graphical XML editor, interface design tool, and graphical database structural design tool, etc. Together, they can find that they have the following common in graphical editing:
Provide an editing area and a toolbar, the user selects the required tool in the toolbar to drag or click on the node or connection to the editing area; the node can contain a child node; the user can view and modify a node Or most of the attributes of the connection; the connection endpoint is anchored on the node; provide the context menu and keyboard command; provide a zoom function of the graphics; provide an outline view, display the thumbnail of the editing area, or a tree model structure; support Undo / Redo the function; etc.
Figure 1 Work interface of the interface design tool (Visual Editor, Ve) based on GEF
GEF is an internal project of Eclipse, which gradually transforms an open source tool project for Eclipse, and many other sub-projects of Eclipse require its support. Eclipse 3.0 has spent a lot of effort to peeled off various functionality from Platform, including the tools, including GEF and IDE, can only be used within Eclipse's software / plug-in packages. In theory, we can get from Eclipse to construct your application with a Gef package, but because of natural links between them, and Eclipse is indeed a very worthwhile development platform, I still recommend you to use it in Eclipse.
The advantage of GEF is to provide a standard MVC (Model-View-Control) structure, and developers can use GEF to complete these features without need to redes themselves. A main design goal of GEF is to minimize the dependence between the model and the view, the advantage of selecting arbitrary models and views, without having to be limited by the development framework (but actually Still rarely out of DRAW2D implementation).
Now let's take a look at how the GEF implements the MVC framework. In this post, we will first introduce it to its various components, and will be described in more detail later.
Figure 2 GEF structure diagram
Model: The gef model is only deal with the controller, and no know anything related to the view. In order to allow the controller to know the change of the model, the controller should be registered as an event listener in the model. When the model changes, the corresponding event is triggered, and the latter is responsible for notifying the various views for updates.
Typical model objects will contain a member variable of the PropertyChangeSupport type to maintain the listener member is the controller; for a model with connection relationship with other objects, maintain the connection / connected connection list; if the node corresponding to the model has a size And location information, we must also maintain them. These variables are not information necessary for the model itself, maintaining the model is not clear enough, but you can maintain their readability by constructing some abstract model classes (for example, inheriting the Node class with all connected model objects).
Relatively speaking, the model in the GEF is the simplest part of the MVC.
Controller: We know that the controller in the MVC structure is the bridge between the model and the view, but also the core of the entire GEF. Not only does it listen to changes in the model, but when the user edits the view, it is also necessary to reflect the results on the model. For example, when the user deletes a table on the database structure diagram, the controller should delete the field objects in this table object, the table in the model, and all connections related to these objects. Of course, these operations are not completed by the direct controller, this will be said later. The controller in GEF is the so-called editpart object, and it is more precisely that a set of EditPart objects together constitute a part of the GEF controller, each model object corresponds to an EditPart object. You need an EditPartFactory object in your application to create a corresponding editpart object based on a given model object, which will be used by view.
Rooteditpart is a special editpart, which does not have any relationship with your model. Its role is to link EditPartViewer and Contents (the top of the application, the most up-tier EDITPART, usually a canvas), you can think of containers in Contents . EditPartviewer has a method setRooteditPart () specifies the RooEditPart for the view.
Figure 3 Editpart object
The user's editing operation is converted to a series of requests, there are many kinds of requests, which are called roles in GEF, and GEF has two major categories of roles in Gef, for example Layout Role corresponds to the operation related to the layout, the latter, such as the Connection Role corresponds to the operation, and the like. The concept is implemented by editing policies (editpolicy), the main function of EditPolicy is based on request to create a corresponding command (Command), while the latter will operate the model object directly. For each EditPart, you can "install" some editpolicy, users will be handed over to the installed corresponding editpolicy processing for this EDITPART. The direct benefit of this is to share some duplicate operations between different editparts.
There is a detailed editpolicy, role, and request type list in the GEF SDK (GEF Development Guide), here is not described here.
View: The view of the GEF can have many kinds of GEF, and GEF currently provides two types of graphicalviewer and TreeViewer. The former uses Draw2D graphics (iFigure) as a manifestation, mostly for editing areas, the latter Then use more to achieve outline display. The task of the view is also heavy, except for the display function of the model, it is necessary to provide editing functions, returningback, tooltip, and more.
GEF uses EditPartViewer as a view, its role and the viewer in the JFAce is very similar, and Editpart is equivalent to its ContentProvider and LabelProvider, specified by the setContents () method. The editor we often use is a GraphicaleditorWithPalette (Editor, which is an EditorPart subclass, with graphical editing area and a toolbar). This Editor uses GraphicaleditViewer and Paletteviewer, PaletteViewer is also a subclass of GraphicaleditViewer. Developers must customize EditPartViewer in both methods of ConfigureGraphicalViewer () and InitializeGraphicalViewer (), including specifying its Contents and EditPartFactory, and more. EditPartViewer is also an ISELECTIONPROVIDER, so when the user selects the selection operation in the editing area, the SelectionChangeListener registered can receive the selection event. EditPartViewer maintains the selection status of each editpart. If there is no EDITPART, the default is the editpart as Contents.
I initially learned the GEF's MVC implementation, let's take a look at what is the typical Gef application looks like. Most GEF applications are achieved for Eclipse Editor, that is, the entire editing area is placed in an Editor. So the typical GEF application has a graphic editing area that is included in an editor (for example, graphicaleditorWithpalette), there may be a largeline view and an attribute page, an EditPartFactory for creating an editpart instance, some model objects that represent the business, with model objects Corresponding to some EditPart, each EditPart corresponds to a subclass of IfitPart displays the user, some EditPolicy objects, and some Command objects.
The GEF application works as follows: EditPartViewer accepts user operations, such as nodes, new or delete, etc., each node corresponds to an editpart object, this object has a set of EditPolicy, which is divided by operation Role, each editpolicy Corresponding to some Command objects, Command finally modify the model. The user's operation is converted to the request assigned to the appropriate editpolicy, which is created by the latter to modify the model. These Command will remain in EditDomain (specifically for maintaining objects such as editpartViewer, Command, usually each of the only one In the command stack of the object, it is used to achieve undo / redo functions.
The above introduces some of the more important concepts in GEF. I don't know if you have a probably impression of it. If there is no relationship, because there will be explanations of the combination example in the posts, the example we use is the sixth project mentioned in the preface.
Reference:
GEF Development Guide Eclipse Developments - Using The Graphical Editing Framework and The Eclipse Modeling Framework
