EMF series (3. Basic Methods for customizing applications)

With the help of EMF, you do not have to write a line in personCodeYou can generate a complete application.ProgramAre you interested in EMF? However, the generated applications seem to come out of the same model, that is
A multi-page editor, an outline view, and an attribute page cannot meet everyone's needs. Don't worry. As long as you understand the EMF mechanism, it is not very difficult to modify this application as required.
Events.

First, let's take a rough look at what EMF has generated for us. According to the previous operations, EMF should generate a total of four plug-in projects: COM. My. shop,
Com. My. Shop. Edit, Com. My. Shop. Editor, and COM. My. Shop. tests. The last project is convenient for us to compile unit tests.
Try the Framework Code. Here we will ignore it and temporarily focus on the first three projects.

The first project is the model part, which mainly includes all types of the ecore model you define (eclass, In the ecore metadatmodel, the type is called eclass, and the attribute is called
Eattribute) Corresponding Java interfaces and default implementation class code, such as product. Java and productimpl. Java, which are placed in
Com. My. Shop and COM. My. Shop. impl packages; a factory class (shopfactory) creates a new model instance in factory mode;
The package class (shoppackage) maintains metadata about the meta-model and provides a bunch of static member variables. In addition, it generates shopadapterfactory and
Shopswitch: These two classes are optional. Their functions are sold here.

The second project is the. Edit section, which contains a series of itemprovider classes to display these Model Objects in various jface viewers.
Convenience. Taking categoryitemprovider as an example, it implements istructureditemcontentprovider,
Itreeitemcontentprovider and iitemlabelprovider
The providers in jface can be considered as packaging the corresponding providers in jface. With these
Provider. It is very convenient to use jface's treeviewer, tableviewer, and other viewers in the application. (In a previous post about GEF
EMF used only the model part to construct the model, because jface viewer was not used. Therefore, depending on your application, only the model part can be generated, and the. Edit part depends on the model part. Otherwise .)

The third project is the editor, which depends on. Edit and mainly contains several UI classes. The editor generated by EMF has two purposes: first, we can modify the editor instead of starting from scratch;
Second, the code shows how to use the classes in the first two projects in the application. The Editor contains so many tabs to demonstrate the usage of various viewers. The following describes how to customize the generated application.
Program.

1. Modify the ecore model and genmodel

In the ecore model and genmodel model, we can modify some attributes to change the generated code. For example, we hope that the newly created category and product name are not empty strings,"
(Unnamed) ", you can modify the" default value "of the name attribute of the namedelement class in the category
Literal "attribute (yes, attribute. See Figure 1 ). After modifying the ecore model, you must update the genmodel in package.
Right-click the shop. genmodel file in the explorer and select "reload..." from the pop-up menu. In this way, genmodel starts from the modified ecore model.
To obtain the modified information. Then, the code is generated from the genmodel model again. After the program runs, the default category and product name is "(unnamed. In
In the genmodel model, you can customize more attributes, such as the ID of each project generated and the package name of the generated class (in this example, Com. my), class name prefix (shop in this example), whether to generate an icon, and category of each attribute on the standard property page.

Figure 1 modifying the default value of an attribute in eclipseuml class Sequence

Someone
The use of the ecore and genmodel models is unclear. In fact, Because Jet directly generates code through genmodel, information such as whether to generate icons is placed in
Genmodel is suitable, and the ecore model defines various types and relationships between them. Therefore, information such as the default attribute values should be placed in ecore.

2. directly modify the generated code

The preceding method enables EMF to generate the program we want. The advantage is that it is very intuitive and convenient. The disadvantage is that only limited information can be customized, however, it is unlikely that a complex application simply enters some
Attributes are generated, so we need code-level customization. There is a fact you need to know: whether you customize the ecore or genmodel model, the results will eventually be reflected in the generated
Code. Let's compare the code before and after modifying the default value of the name (because the class named namedelement is defined as an abstract class, the position of this Code is
Categoryimpl. Java and productimpl. Java). This is the code generated earlier:

/**
* The default value of '{ @ Link # Getname () <em> name </em>} 'attribute.
* <! -- Begin-user-doc -->
* <! -- End-user-doc -->
* @ See # Getname ()
* @ Generated
* @ Ordered
  */
Protected   Static   Final String name_edefault =   Null ;

The following code is customized:

/**
* The default value of '{ @ Link # Getname () <em> name </em>} 'attribute.
* <! -- Begin-user-doc -->
* <! -- End-user-doc -->
* @ See # Getname ()
* @ Generated
* @ Ordered
  */
Protected   Static   Final String name_edefault =   " (Unnamed) " ;

We can see that the value of name_edefault has changed. That is to say, if we do not modify the ecore model, but manually modify this code, we can achieve the same purpose. Familiar
For EMF developers, code modification is usually faster than modifying the ecore/genmodel model (because the reload is saved
Genmodel and code generation), but remember to modify the javadoc before the code. Because every time the Code is re-generated, jet uses the original
The javadoc before the Code determines whether to overwrite the Code. If javadoc contains a line "@ generated", it overwrites the code. Otherwise, the Code remains unchanged. In order for us to manually
The modification does not disappear in future generation (this is a huge loss). You can directly Delete the @ generated line. A better way is to change it to a unified string, for example
"@ Generated not", so that you can use the javadoc search to find out where you have made manual changes.

The following example shows how to modify the code generated by EMF. Suppose there is a demand that all products with a price greater than or equal to 100 yuan will be automatically converted to off, and products with a price less than 5 yuan will be calculated as 5 yuan, then we need to modify the getprice () method of productimpl. The code before modification is as follows:

/**
* <! -- Begin-user-doc -->
* <! -- End-user-doc -->
* @ Generated
  */
Public   Double Getprice (){
Return Price;
}

This is the modified Code. Remind me again not to forget to modify the @ generated line comment:

/**
* <! -- Begin-user-doc -->
* All products with a price greater than or equal to 100 yuan will be automatically converted to off, and products with a price less than 5 yuan will be charged as 5 yuan.
* <! -- End-user-doc -->
* @ Generated not
  */
Public   Double Getprice (){
If (Price > =   100 )
Return Price *   0.95 ;
If (Price <   5 )
Return 5D;
Return Price;
}

As for the method used for customization, I personally suggest that you do not directly modify the code if you solve the problem by modifying the ecore/genmodel model. To minimize the number of manual modifications, you can keep your ideas clear, in fact, in actual use, most of the customization is implemented only by modifying the code.

Click here to download the modified project.