Eclipse Modeling Framework

Description

• Copyright 2004
• Edition: 1st

• Book
• ISBN-10: 0-13-142542-0
• ISBN-13: 978-0-13-142542-2

A new edition of this title is available, ISBN-10: 0321331885 ISBN-13: 9780321331885



Downloads

Downloads

To aid in your work with Eclipse Modeling Framework: A Developer's Guide, we are making available all the example code and models appearing in the book. You can import the code and models into a project in your Eclipse workspace for easy access.

Once you have downloaded and decompressed the code archive, please see the file examples/readme.txt for information on generating and running the examples. This file, as well as the readme files in the subfolders, provide the necessary information for working with the code and models.

Download the archive (ZIP, 136 kb).



Sample Content

Downloadable Sample Chapter

Download the Sample Chapter related to this title.

Table of Contents

Foreword by Sridhar Iyengar.


Foreword by Dr. Lee R. Nackman.


Preface.


References.

I. EMF OVERVIEW.

1. Eclipse.

The Projects. The Eclipse Platform. More Information.

2. Introducing EMF.

Unifying Java, XML, and UML. Modeling vs Programming. Defining the Model. Generating Code. The EMF Framework. EMF and Modeling Standards.

3. Model Editing with EMF.Edit.

Displaying and Editing EMF Models. Item Providers. Command Framework. Generating EMF.Edit Code.

4. Using EMF—A Simple Overview.

Example Model: The Primer Purchase Order. Creating EMF Models and Projects. Generating Code. Running the Application. Continuing Development.

II. DEFINING EMF MODELS.

5. Ecore Modeling Concepts.

Core Model Uses. The Ecore Kernel. Structural Features. Behavioral Features. Classifiers. Packages and Factories. Annotations. Modeled Data Types.

6. Java Source Code.

Java Specification for Packages. Java Specification for Classes. Java Specification for Enumerations. Java Specification for Data Types. Java Specification for Maps.

7. XML Schema.

Schema Definition of Packages. Schema Definition of Classes. Schema Definition of Attributes. Schema Definition of References. Schema Simple Types.

8. UML.

UML Packages. UML Specification for Classifiers. UML Specification for Attributes. UML Specification for References. UML Specification for Operations.

III. USING THE EMF GENERATOR.

9. EMF Generator Patterns.

Modeled Classes. Attributes. References. Operations. Class Inheritance. Reflective Methods. Factories and Packages. Switch Classes and Adapter Factories. Customizing Generated Classes.

10. EMF.Edit Generator Patterns.

Item Providers. Item Provider Adapter Factories. Editor. Action Bar Contributor. Wizard. Plug-Ins.

11. Running the Generators.

EMF Code Generation. The Generator GUI. The Command-Line Generator Tools. The Template Format.

12. Example—Implementing a Model and Editor.

Getting Started. Generating the Model. Implementing Volatile Features. Implementing Data Types. Running the ExtendedPO2 Editor. Restricting Reference Targets. Splitting the Model into Multiple Packages. Editing Multiple Resources Concurrently.

IV. PROGRAMMING WITH EMF.

13. EMF Client Programming.

Packages and Factories. The EMF Persistence API. EMF Resource Implementations. Adapters. Working with EMF Objects. Dynamic EMF.

14. EMF.Edit Programming.

Overriding Commands. Customizing Views.

V. EMF API.

15. The org.eclipse.emf.common Plug-In.

The org.eclipse.emf.common Package. The org.eclipse.emf.common.command Package. The org.eclipse.emf.common.notify Package. The org.eclipse.emf.common.util Package.

16. The org.eclipse.emf.common.ui Plug-In.

The org.eclipse.emf.common.ui Package. The org.eclipse.emf.common.ui.celleditor Package. The org.eclipse.emf.common.ui.viewer Package.

17. The org.eclipse.emf.ecore Plug-In.

The org.eclipse.emf.ecore Package. The org.eclipse.emf.ecore.plugin Package. The org.eclipse.emf.ecore.resource Package. The org.eclipse.emf.ecore.util Package.

18. The org.eclipse.emf.ecore.xmi Plug-In.

The org.eclipse.emf.ecore.xmi Package.

VI. EMF.EDIT API.

19. The org.eclipse.emf.edit Plug-In.

The org.eclipse.emf.edit Package. The org.eclipse.emf.edit.command Package. The org.eclipse.emf.edit.domain Package. The org.eclipse.emf.edit.provider Package. The org.eclipse.emf.edit.provider.resource Package. The org.eclipse.emf.edit.tree Package. The org.eclipse.emf.edit.tree.provider Package. The org.eclipse.emf.edit.tree.util Package.

20. The org.eclipse.emf.edit.ui Plug-In.

The org.eclipse.emf.edit.ui Package. The org.eclipse.emf.edit.ui.action Package. The org.eclipse.emf.edit.ui.celleditor Package. The org.eclipse.emf.edit.ui.dnd Package. The org.eclipse.emf.edit.ui.provider Package.

Appendix A: UML Notation.

Classes and Interfaces. Enumerations and Data Types. Class Relationships.

Appendix B: Summary of Example Models.

SimplePO. PrimerPO. ExtendedPO1. ExtendedPO2. ExtendedPO3.

Index.

Index

Download the Index file related to this title.



Updates

Errata

Typographic Errors

• Page 52. In paragraph 3, "EMF.Edit Commands" should be "EMF.Edit commands".
• Page 348. In paragraph 3, xsi.schemaLocation should be xsi:schemaLocation.
• Page 361. The line of text following the first code fragment should be regular font.

EMF Design Changes

Because we strived to produce a book covering the most current release of EMF, we needed to write it concurrently with the ongoing design and development of EMF version 1.1. Although we tried our best to reflect every recent design change, we inevitably missed a few. The ones we know about are listed below.

• Page 25. The EMF generator has been changed to allow greater control over how it merges extends and implements clauses, by recognizing an @extends Javadoc tag, which is described in Section 9.9. In the last paragraph, "and they will be" should be replaced by "and specify that they should be", to reflect this change. Also, "would be overwritten" should be replaced by "will always be overwritten".
• Page 82. A late change in the EMF framework has eliminated the automatic creation of packages for data types that do not have corresponding types in Ecore. Therefore, in version 1.1 of EMF, the New Project wizard does not include the schema package as shown in Figure 4.16, and simply uses EString instead of the manufactured Date and Decimal data types described in the example (see also p. 140 erratum).
• Page 140. In EMF version 1.1, all simple types that do not derive from any type in Table 7.1 do not map to a manufactured EDataType as described in the last paragraph, but instead map simply to the built-in Ecore type EString. In future releases, EMF will fully support data types created from schema simple types.
• Page 212. The newly added @extends tag may be used on classes, as well as interfaces. Thus, the last paragraph should read as follows: "The user section of the Javadoc comment associated with an interface or class may also contain a special control directive used during merging: the @extends tag, followed by a comma-separated list of interfaces. The generated interface's extends clause (or class' implements clause) will be merged with this list. This allows you to add non-generated super-interfaces, without removing the @generated tag."
• Page 238. When support for different character encodings was added to EMF, the generator pattern for the wizard class was affected. In the first code fragment, the last line shown of performFinish() should be replaced by the following:

    Map options = new HashMap();
    options.put(XMLResource.OPTION_ENCODING,
                initialObjectCreationPage.getEncoding());
    resource.save(options);
  

  This uses the OPTION_ENCODING option (see p. 319) to set the character encoding for the persistent form that is created, as set by the user on the last page of the wizard.

• Page 288. The code fragment is based on the wizard generator pattern that did not set the character encoding (see p. 238 erratum). The last line shown should be replaced by the following:

    Map options = new HashMap();
    options.put(XMLResource.OPTION_ENCODING,
                initialObjectCreationPage.getEncoding());
    resource.save(options);
  

  In this example, we remove the last page from the wizard, which would make the generated call to initialObjectCreationPage.getEncoding() fail. So, we simply remove that, too, and the default encoding is used.

• Page 363. The example in Section 14.2.1 assumes, again, that the wizard generator pattern does not set the character encoding (see p. 238 erratum). Since the last page of the wizard is removed, again we need to remove the line of code from performFinish() that attempts to set the encoding option based on it.
• Page 366. In addition to adding interface ITableItemLabelProvider to the implements clause of PurchaseOrderItemProvider, we should also add an @extends tag to the Javadoc for the class, as follows:

    /**
     * This is the item provider adpater for a
     * {@link com.example.epo1.PurchaseOrder} object.
     * <!-- begin-user-doc -->
     * @extends ITableItemLabelProvider
     * <!-- end-user-doc -->
     * @generated
     */
    public class PurchaseOrderItemProvider
  

  This ensures that the change will be retained during regeneration (see p. 212 erratum).

• Page 369. Section 14.2.2 should point out that, by default, the generated PurchaseOrderItemProvider class disables change notification for non-containment references. Because the customer reference in class PurchaseOrder is such a reference but is now displayed in our table viewer, we need to enable notification for it. We do this by simply setting the "Notify" property in the generator model (see p. 254) to true for the customer reference, before generating the model.
• Page 375. Section 14.2.3 should describe one additional change that is required in SupplierItemProvider. Its notifyChanged() method should be modified as follows:

    /**
     * @generated NOT
     */
    public void notifyChanged(Notification notification)
    {
      switch (notification.getFeatureID(Supplier.class))
      {
        case EPO1Package.SUPPLIER__NAME:
        case EPO1Package.SUPPLIER__CUSTOMERS:
        case EPO1Package.SUPPLIER__ORDERS:
        {
          fireNotifyChanged(notification);
          return;
        }
      }
      super.notifyChanged(notification);
    }
  

  That is, it should not fire notifications for the orders or customers features, which now affect the "Customers" and "Orders" nodes, rather than the supplier, itself. The two new item providers already fire these notifications, substituting themselves for the actual notifier (see p. 372). Without the above change to SupplierItemProvider, the viewer would see the same notifications both from the appropriate non-modeled node and from the supplier.

Submit Errata

