Generic Editor

Introduction
How to Use the Generic Editor
Working with Dynamic Instances
Model Validation
Customizing Icons and Labels
Proposals

Introduction

The generic editor can be used to edit any EMF models even dynamic instances. The generic editor combines the power and flexibility of EMF's reflective editor with the usability and elegance of Eclipse Forms. The user can also dynamically provide constraints and icon and label providers using oAW. Note: EMF Databinding is required.

How to Use the Generic Editor

The user interface of the generic editor is easy to use. It is based on a master/detail component. The master section shows the model tree, while the individual properties of the selected element can be edited in the details section. In the toolbar there is also a validation button integrated. This button can be used to check the model based on the used validation mechanism (see next paragraph).

Figure 27. Generic Editor

Generic Editor


Working with Dynamic Instances

The editor can of course be used with installed EPackages. In that case the validation is done using the EValidationRegistry and the labels and icons are computed using EMF's ComposedAdapterFactory.Descriptor.Registry . As this is exactly how EMF's reflective editor works there is not much added value besides the use of forms instead of the properties view.

Using the generic editor becomes more interesting when it comes to dynamic instances. A dynamic instance is an instance of an Ecore model which has not been installed into the workbench. The use of dynamic instances only makes EMF's code generator obsolete and reduces turnaround times significantly. In order to create a dynamic instance, all you have to do is open (or create) an Ecore file in your workspace, select an EClass and use the context menu to "create a dynamic instance". The action creates a new file and puts an instance of the selected EClass as it's root element. Using the generic editor one can not only edit theses dynamic models, but also specify constraints. In addition one can define how labels and icons should be computed, all dynamically without the need to install bundles into eclipse or restart the workbench.

Model Validation

To get your dynamic models validated all you have to do is provide a oAW Check file for the metamodel. The editor will validate the model on startup, on save and each time the check button is pushed. There are some prerequisites about that:

  • the project must have the openArchitectureWare nature enabled
  • the check file must be named Checks.chk , and
  • the check file must be placed in yourEPackageName package in project's source folder

A typical check example for an entity Library could look like this:

				context Library WARNING "name#Library should have a
				name": !this.name.isEmpty();
			

The suffix "name#" in the message says that this warning refer to the feature name. With this additional information the generic editor can provide a hyper link and add a marker for the respective feature.

Customizing Icons and Labels

To customize the presentation of the model elements in the editor you can provide label() and icon() extensions. Those extensions are found if:

  • the project has the openArchitectureWare -Nature enabled
  • the extension file is named ItemLabelProvider.ext , and
  • the extension file must be placed in yourEPackageName package in project's source folder
  • the extension names are label for a label and icon for an icon
  • they have one parameter with the according type
  • corresponding icons must be placed in a folder /icons/yourEPackageName (not necessarily on the classpath)

Example:

				//book String label(Book ctx):
				ctx.title.isEmpty()?"Untitled book":ctx.title;

				String icon(Book ctx): "book.gif";
			

This example shows how a custom label and icon can be computed for an EClass called Book . The extension label sets a book's label to title or to "Untitled book" if it is empty. The extension icon sets icons/yourEPackageName/book.gif image as a book's icon instead of default one.

Proposals

When setting a reference or an enumeration literal by default the editor provides all elements which would fit (i.e. they are of the reference's type). Sometimes these lists get very long. In order to filter and sort such lists of proposed elements one also can specify an extension For these extensions to be found :

  • the project must have the openArchitectureWare nature enabled
  • the extension file must be named Proposals.ext , and
  • the extension file must be placed in yourEPackageName package within project's source folder
  • the extension's signature is: List[ReferencedMetaType] featureName(MetaType ctx, List[ReferencedMetaType] list)

In the following example one can only select from 'active' authors when setting the author for a book. All the authors are sorted by name:

				//reference proposal/filter List[Person] author(Book
				ctx,List[Person] l):
				l.select(e|e.isActive).sortBy(e|e.name);
			

It is also possible to provide code completion for text attributes. The example below shows how to create a name -proposal for Entity Person , containing John and the names of all Persons already in the model.

				//attribute proposals
				List[String] name(Person ctx):
										{"John"}.addAll(ctx
															.eRootContainer
															.eAllContents
															.typeSelect(Person)
															.collect(e|e.name))
																.toSet()
																.toList();