Eclipse GEF (2) MVC

An introduction to draw2d was made in the previous eclipse GEF, which is primarily a part of the GEF (MVC). The MVC in GEF is as follows:

In short, the view layer views is what we can see, model models mainly store the data displayed, after all, graphics are only graphics can not contain any meaningful things, we operate any data to be stored in the model layer, controller is a very busy role, it is always on standby, The model data is transmitted to the view layer, which eventually forms the graphics and data we see.

In the previous article the figure of the class diagram, that we use draw2d as our view layer, but only have views, no other useful functions, the following examples for our example to add some practical features.

First of all, the API in the interface and the class do not do too much analysis, in the subsequent article has the opportunity to write, first we have to define a controller, in the Gef/editpart package for us to encapsulate a class: Abstractgraphicaleditpart, This class encapsulates some of the ways in which graphics operations are needed (such as adding connections between graphs), eliminating the need for us to write graphical Editpart. Let's create a Umleditpart class that inherits Abstractgraphicaleditpart so that our Abstractumleditpart has graphics Editpart-related functionality, and implement Nodeeditpart interface, so that our Editpart class has node Editpart function.

The Umleditpart class without any implementation method is as follows:

 PackageCom.blog.uml.editpart;ImportOrg.eclipse.draw2d.ConnectionAnchor;ImportOrg.eclipse.draw2d.IFigure;ImportOrg.eclipse.gef.ConnectionEditPart;ImportOrg.eclipse.gef.NodeEditPart;ImportOrg.eclipse.gef.Request;ImportOrg.eclipse.gef.editparts.AbstractGraphicalEditPart; Public  class umleditpart extends Abstractgraphicaleditpart implements  nodeeditpart{    method declared in//nodeeditpart, gets the source connection anchor according to Connectioneditpart    @Override     PublicConnectionanchorGetsourceconnectionanchor(Connectioneditpart arg0) {//TODO auto-generated method stub        return NULL; }the method that is declared in//nodeeditpart, gets the source connection anchor according to request    @Override     PublicConnectionanchorGetsourceconnectionanchor(Request arg0) {//TODO auto-generated method stub        return NULL; }//Get Target connection anchor    @Override     PublicConnectionanchorGettargetconnectionanchor(Connectioneditpart arg0) {//TODO auto-generated method stub        return NULL; }@Override     PublicConnectionanchorGettargetconnectionanchor(Request arg0) {//TODO auto-generated method stub        return NULL; }//Create figure    @Override    protectedIfigurecreatefigure() {//TODO auto-generated method stub        return NULL; }//Create Editpolicies    @Override    protected void createeditpolicies() {//TODO auto-generated method stub}}

The above method does make people confused for the first time, and it may be easy to understand if you have a good understanding of the GEF, but for the first look (learning about the GEF must be familiar with Java), there are many unfamiliar analogies such as request, editpolicy, which involve the architecture of the GEF.

Is the ECLIPSEHELP in the GEF Classic High-level view on the right side of interaction boundary part of the controller, Model, figure how much we are familiar with, and Editpartviewer, A editpart if you want to show its view, you have to have a backing, which is called editpartviewer, or the bearer of the view.

Editpart Introduction
Editpart is associated with views and models, but also has its own structure, same as figure and model, Editpart also maintains sub-editpart, for example, a model may be composed of a graph containing multiple nodes, The Editpart of the same graph may also contain a multi-node figure Edipart Child:

Now, assuming that you are editing the Edipart, the interaction between the model and the view will be generated during the editing process as follows:
1. The so-called interaction must be caused by the event, such as keyboard, mouse, drag and so on, so before sending these interactive requests must be determined to which editpart processing (in fact, the process to be more complex), in the operation of the mouse, you can think that the target is the mouse pointing to that part, Of course, some operations do not have target.
2. Some interactive operation is to need feedback, such as the mouse is dragging a vertex in the graph, because our mouse has been pointing to the part of the graph, or we move the node, just want to put the node into a map of a certain coordinates, the target is this map, and the moving node is the source, Source is the object being manipulated, the source will be placed at the end of the corresponding target, which is the difference between target and source, the English meaning is very consistent with this feature, when the mobile node source as mentioned in the beginning, each step needs feedback, That is, the node is actually moved.
3. The above operation is now only through the user, Editpart and views, has not been modal, so the next step must be related to modal, since the interactive view of a part of the corresponding changes, the associated modal property values will inevitably occur corresponding changes, A property change is a command that is designed to accept commands issued by Editpart for modal to make corresponding changes, although if the command is considered non-executable, it is also reflected to the user of the operation

editpolicies

Editpart does not directly handle the request, but instead delegates to editpolicy processing, each editpolicy is concerned with a editing, so you need to specify some editpart when creating editpolicy. This design mode can be easily added to the Editpart function.

Editdomain
The editing domain is a management-aware class that binds an editor, several viewers, and several tools. So it defines the real editor. The edit domain also provides a command stack to hold all executed commands with two benefits:
1. Redo and no-do operations can be achieved
2. To see if the model has been altered.

The Selection Tool

In modern applications, one of the most important functions that a program implements is drag and drop.

To make it easier for users to drag and drop in the GEF application, the GEF itself provides classes and concepts. For example, you do not need to deal with SWT's Drag source object [DragSource] and other low-level objects.

In GEF, what the user needs to do is add the drag source listener [Transferdragsourcelistener] and drag the target listener [Transferdrogtargetlistener] to the editor Viewer [Editpartviewer]. The former can make the editor viewer a drag-and-drop source, which allows the user to pull out of the editor viewer, which makes the edit viewer a drag target, allowing the user to drag it into the editor viewer.

When dragging listeners for the viewer in the GEF application, make sure that the class inherits the parent class from the GEF framework.

Drag-and-drop principle: When a user pulls out of a viewer that supports a drag source, the GEF framework produces a corresponding template object that gets the class information that the user wants to create the object from the framework. When the user releases the mouse over the viewer that supports the drag-and-drop target, the drag-and-drop event is generated, and the Templatetransferdroptargetlistener object creates the corresponding instance from the template object.

Eclipse GEF (2) MVC