Constructing a GEF application is usually divided into several steps: Designing the model, designing the Editpart and figure, Designing the Editpolicy and command, where Editpart is the most important part, because it is inevitable when it is implemented To use the Editpolicy, the latter involves command.
Now let's take a look at an example its function is very simple, the user can increase the node and the connection between nodes on the canvas, can directly edit the name of the node and change the location of the node, the user can undo/redo any action, have a tree outline view and a property page. This is an Eclipse Project packaging file that runs Run-time Workbench after import in Eclipse, and a new file with an extension of "Gefpractice" opens the editor.
Fig. 1 Practice Editor User interface
You can refer to the code to see what's coming up, let's start with the model. The model is designed according to the application requirements, so our model includes diagram representing the entire graph, node representing nodes, and connection those objects that represent the connection. We know that the model is responsible for informing the editpart of our changes, and in order to isolate this function, we use the abstract class named element to implement the notification mechanism, and then let the other model classes inherit it. The element class includes a member variable of the Propertychangesupport type and provides Addpropertychangelistener (), Removepropertychangelistener (), and The Firexxx () method registers the listener and notifies the listener model to change events, respectively. In GEF, the model listener is Editpart, and in the Editpart active () method we register it as a listener in the model. So, a total of four classes make up our model section.