[Eclipse] GEF Getting Started series (Viii. models using EMF to construct GEF)

The GEF design does not impose any restrictions on the model part, that is, we can construct our own model arbitrarily, the only thing to be assured is that the model has some kind of message mechanism to be able to notify GEF (via Editpart) when the change occurs. In previous examples, we used the Propertychangesupport and PropertyChangeListener in the Java.beans package to implement the message mechanism, and here's how to get GEF to take advantage of the EMF-constructed model.

EMF uses its own defined ecore as the Metamodel, in which the concepts of epackage, Eclassifier, Efeature, and so on are defined, and the models we define are defined using these concepts. At the same time because all the concepts in Ecore can be defined by their own concept cycle, so ecore is its own meta model, that is, the metamodel. For detailed concepts on Ecore, please refer to the relevant information on the EMF website.

Using EMF to generate model code for us can be done in a variety of ways, such as through XML schemas, annotated Java interfaces, Rose's MDL files, and. ecore files, and so on, EMF code generators require a file with an extension of. Genmodel to provide information, This file can be generated in several ways, and I recommend using the Omondo Company's ECLIPSEUML plug-in to construct the. ecore file, which can be downloaded from this free version of the plugin. (You may need to use a foreign agent to access the Omondo Web site)

Figure 1 Sample Model

To save space and time, I'm not going to elaborate on the steps to construct an EMF project, which is a description of the difference between using EMF and non-EMF models. Figure 1 is the model used in the example where dimension and point are two external Java types, and are defined as datatype types because EMF does not understand them.

Use two plugins

In order for the model to be better detached from the editor, the EMF model can be located in a single plugin (named Subjectmodel), and the editor plugin (subjecteditor) depends on it. Another benefit of doing this is that when you modify the model, you can easily delete the previously generated code and regenerate it all if you like.

Modifications in the Editpart

In the past our editpart is to implement the Java.beans.PropertyChangeListener interface, when the model instead of EMF implementation, Editpart should implement the Org.eclipse.emf.common.notify.Adapter interface instead, because each model object of the EMF is Notifier, which maintains a adapter list that can be added as a listener To this list in the model.

Implementing the adapter interface requires the implementation of the Gettarget () and Settarget () methods, and target represents the model object that emitted the message. My implementation is to maintain a notifier type of target variable in Editpart, which returns and sets the variable separately.

Also implement the Isadapterfortype () method, which returns a Boolean value that indicates whether this adapter should respond to a specified type of message, all my implementations are "return Type.equals (Getmodel (). GetClass ());".