[Eclipse] GEF entry series (III. Application Instances)

Construct a GEF applicationProgramThere are usually several steps: Design Model, design editpart and figure, design editpolicy and command. editpart is the most important part, because editpolicy must be used when implementing it, the latter involves command.

Now let's look at an example. Its function is very simple. You can add connections between nodes on the canvas. You can directly edit the node name and change the node location, you can undo/Redo any operation with a tree Outline View and an attribute page. Click here to download (Update: For eclipse 3.1). This is an Eclipse project package file. After importing it in eclipse, run-time workbench, create a new file with the extension "gefpractice" to open the editor.

Figure 1 use interface of practice Editor

You can referCodeLet's start with the model. The model is designed based on application requirements. Therefore, our model includes digraphs representing the entire graph, nodes representing the node points, and connection Objects representing connections. We know that the model is responsible for notifying editpart of changes. to separate this function, we use the abstract class named element to implement the notification mechanism, then let other model classes inherit it. The element class contains a member variable of the propertychangesupport type, and provides the addpropertychangelistener (), removepropertychangelistener (), and firexxx () Methods to register the listener and notify the listener model change events respectively. In GEF, the model listener is editpart. In the active () method of the editpart, We will register it as the listener to the model. Therefore, a total of four classes constitute our model.

As mentioned in the previous post, most GEF applications are implemented as editors. This example is no exception. The corresponding editor is called practiceeditor. This editor inherits the graphicaleditorwithpalette class, indicating that it is a graphic editor with a color palette. The two most important methods are configuregraphicalviewer () and initializegraphicalviewer (), which are used to customize and initialize editpartviewer respectively. (For the role of editpartviewer, see the previous post ), after a brief look at the GEF code, you will find that the two methods are called successively in the graphicaleditor class, but a hookgraphicalviewer () method is inserted in the middle, its role is to synchronously select and register editpartviewer as selectionprovider to the site (site is the concept of workbench. Please refer to eclipse for help ). Therefore, initialization operations unrelated to selection should be completed in the former; otherwise, the initialization operations should be completed in the latter. In the example, in the two methods, we have configured the rooteditpart, The editpartfactory used to create the editpart, the contents is the digoal object, and added the drag-and-drop support. The drag target is the current editpartviewer, the drag source is the color palette.

This editor has a palette, so we need to tell GEF what tools are available in our palette, which is implemented by overwriting the getpaletteroot () method. In this method, we construct a paletteroot object using a tool class palettefactory written by ourselves and return it. In our palette, we need three tools: tool selection, node tool, and Connection Tool. In GEF, there can be a drawer (palettedrawer) in the palette to classify and place various tools. Each tool is a toolentry, selectiontoolentry and connectioncreationtoolentry) it is two of several predefined tools, so it can be used directly. For a node tool, use combinedtemplatecreationentry and pass the node type as one of the parameters. The code for creating a node tool is as follows.

Toolentry tool =NewCombinedtemplatecreationentry ("Node", "Create a new node", node.Class,NewSimplefactory (node.Class),Null,Null);
 

In the new version 3.0, GEF also provides an editor graphicaleditorwithflyoutpalette that can automatically hide the color palette. You can select more options for the appearance of the color palette, later posts may mention how to use it.

the initialization of the color palette should be completed in initializepaletteviewer (). The main task is to add Drag Source event support for the editpartviewer of the color palette, we have added a drag target event for the editpartviewer of the canvas, so now we can complete the drag and drop operations. Here we will explain the implementation principle of drag-and-drop. Taking the node tool used to create node objects as an example, it is a combinedtemplatecreationentry in the color palette. When creating this paletteentry (see the above Code) we specify that this object corresponds to a node. class, so when you drag this tool from the palette, A templatetransfer singleton object in the memory will record the node. class (called template). When you release the mouse on the canvas, the drag-and-drop event is triggered. The diagramtemplatetransferdroptargetlistener object registered on the canvas processes the template object (now node. class). In this example, we use an object named elementfactory to create an instance of the corresponding type based on this template.

We have created a model and an editor for implementing the view. Because the changes to the model are directly modified by the command object, we will first look at the commands available. According to the requirements, we can add/delete nodes, modify node names, change node locations, and add/delete connections for model operations, therefore, objects such as createnodecommand, deletenodecommand, renamenodecommand, movenodecommand, createconnectioncommand, and deleteconnectioncommand are stored in the commands package. The most important thing in a command object is the execute () method, that is, the method for executing the command. In addition, the Undo () and redo () methods are available in the command object to implement the Undo/Redo function, at the same time, a member variable in the command object should be responsible for retaining the relevant status when the command is executed. For example, the renamenodecommand must have two variables, oldname and newname, so that the Undo () can be correctly executed () and redo () methods, remember that every executed command object instance is saved in the commandstack of editdomain.

The editpolicy in this example is placed in the policies package. diagramlayouteditpolicy, nodedirecteditpolicy, and nodegraphicalnodeeditpolicy are related to the graph (subclass of graphicaleditpart). The other two are graph-independent editing policies. We can see that in the last two classes (connectioneditpolicy and nodeeditpolicy), we only cover the createdeletecommand () method, this method is used to create a command object responsible for the "delete" Operation and return it. To find out the seemingly conflicting names of this method, create and delete are for different objects.

With command and editpolicy, you can now look at the editpart section. Each model object corresponds to an editpart. Therefore, the three model objects (the element is not counted) correspond to diagrampart, connectionpart, and nodepart respectively. For editpart containing child elements, the getmodelchildren () method must overwrite the list of sub-objects returned by the getmodelchildren () method. For example, in diagrampart, this method returns the Node object column table contained by the digoal object.

Each editpart has two methods: active () and deactive (). Generally, we register the listener in the former (because the propertychangelistener interface is implemented, the editpart itself is the listener) to the model object, remove the listener from the list in the latter. In the propertychange () method that triggers a listener event, it is generally used to determine the method used to refresh the view based on the "event name". For example, if the node attributes are changed for nodepart, call the refreshvisuals () method. If the connection related to it changes, call refreshtargetconnections () or refreshsourceconnections (). The event names used here are defined by ourselves. In this example, node. prop_name indicates the node name attribute, node. prop_location indicates the node location attribute, and so on.

Editpart (abstractgraphicaleditpart) Another important method to be implemented is createfigure (). This method should return the graphical representation of the model in the view, which is an ifigure object. Generally, these images are placed in the figures package. In this example, only nodefigure has a custom image. The digoal object corresponds to the freeformlayer image that comes with GEF, it is a layer image that can be expanded at any time in the Southeast and northwest directions. The connection corresponds to the GEF built-in image called polylineconnection, which is a line used to connect the other two images by default, in this example, we use the settargetdecoration () method to display an arrow on the target end of the connection.

Finally, add an appropriate editpolicy for the editpart, which is implemented by overwriting the createeditpolicies () method of the editpart, each editpolicy in the "installed" to the editpart corresponds to a character string used to represent the role. An editpolicy is usually installed for editparts with child elements in the model. the editpolicy of the layout_role role (see the code below). The latter is a subclass of the layouteditpolicy. For the connection type editpart, The editpolicy is usually installed. the editpolicy of the connection_endpoints_role role. The latter is mostly the connectionendpointeditpolicy or its subclass.

 
Installeditpolicy (editpolicy. layout_role,NewDiagramlayouteditpolicy ());
 

User operations are converted to requests by the current tool (selectiontool by default). Requests are distributed to the editpolicy installed in the target editpart according to the type, the latter determines whether to create and execute commands Based on the role corresponding to the request.

As mentioned in previous posts, role-editpolicy-command is designed to reuse code as much as possible. For example, the same editpolicy can be installed in different editparts, the same command can be used by different editpolicies. Of course, there are advantages and disadvantages in everything. I think this design also has disadvantages. First of all, it seems that the Code is not intuitive enough. You must understand many role and editpolicy and increase the learning cycle; in addition, most of the Code that does not need to be reused must be written according to this relatively complex formula, resulting in additional work.

The above is the most basic component of a GEF application. Some functions such as direct edit, attribute table, and outline view are not described in this example, the following post will introduce the implementation of these common functions.