Home > Resources > Errata >
     
Resources
Errata

Updates and Corrections

The following is a list of all known errors in The Eclipse Modeling Framework: A Developer's Guide as of August 8, 2003. We invite your comments and suggestions for improving the text.

Typographic Errors

This is a list of known minor errors in the typesetting of the book.

  • 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.



Copyright © 1995-2010, Pearson Education, Inc. Legal and Privacy Terms