![](bg2.png)
support, and other convenience classes that allow
EMF models to be displayed using standard desktop
(JFace) viewers and property sheets. Moreover,
it also provides a command framework, with a
set of generic command implementation classes for
building editors that support fully automatic undo and
redo. These functionalities are dealt with by relying
on an editing domain which manages a self-contained
set of interrelated EMF models and the commands
that modify them.
Most of these functionalities can be tied together
by using adapter factories which can transparently
bind the mechanisms of the EMF.Edit framework to-
gether with the UI functionalities, so that, for in-
stance, labels for the viewer’s elements can be re-
trieved automatically. The main problem for the pro-
grammer is still that all these mechanisms have to be
setup and initialized correctly in order to achieve the
desired functionalities; and this initialization might
still be a burden for the programmer since it requires
many lines of code, which are recurrent, require some
deeper knowledge, and tend to fill the code with too
many distracting details. In Listing 1 we show the
typical Java code which is very recurrent in appli-
cations that use EMF models and UI functionalities
(based on the above describe EMF.Edit framework).
We note that such code is full of too many recurrent
code with many internal details. As we will show in
the next sections, our goal is to factor out this recur-
rent code in such a way that UI components (such as
the viewer in the Listing) can be setup with only a
few lines of code (see Listing 6, Section 3.1). Note
that from Listing 1 we intentionally omitted all the
instructions to load the actual resource of the EMF
model, which requires some additional (and recur-
rent) effort. Finally, while the code presented in List-
ing 1 deals with a viewer with editing functionalities,
still, even in the case of a viewer in read-only mode,
many instructions would be required.
EMF standard generation mechanisms are based
on specific Javadoc comments, i.e., @generated, for
fields, methods and classes. The idea behind these
generation mechanisms is that future generation will
overwrite all the previously generated Java code ele-
ments unless the user removes that @generated from
specific declarations (or replaces it with @generated
NOT); thus, for instance, if in a generated Java class
we want to modify a specific generated method with
a custom implementation, we can remove that @gen-
erated from the method’s Javadoc, and the next time
we run EMF generation, that method will not be over-
written.
An example of customization of labeling in a class
generated by EMF into the edit plugin (related to the
1 adapterFactory = new ComposedAdapterFactory(
ComposedAdapterFactory.Descriptor.Registry.
INSTANCE);
adapterFactory.addAdapterFactory(new
ResourceItemProviderAdapterFactory());
3 adapterFactory.addAdapterFactory(new
MyModelItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(new
ReflectiveItemProviderAdapterFactory());
5
BasicCommandStack commandStack = new
BasicCommandStack();
7 commandStack.addCommandStackListener
(new CommandStackListener() {...});
9
editingDomain = new AdapterFactoryEditingDomain(
adapterFactory, commandStack, ...);
11
Tree tree = new Tree(composite, SWT.MULTI);
13 TreeViewer viewer = new TreeViewer(tree);
15 viewer.setContentProvider(new
AdapterFactoryContentProvider(adapterFactory)
);
viewer.setLabelProvider(new
AdapterFactoryLabelProvider(adapterFactory));
17 viewer.setInput(editingDomain.getResourceSet());
19 new AdapterFactoryTreeEditor(viewer.getTree(),
adapterFactory);
Listing 1: An example of typical recurrent use of EMF
functionalities.
classic EMF Library example) is shown in Listing 2.
We observe that even for specifying the image for
instances of Book we need to go into the generated
ItemProvider class, and specify the path of the im-
age, but also other distracting details (like overlay-
Image, ResourceLocator, etc.). Furthermore, if we
want to customize the images for all the EClasses of
our model, we need to modify every generated Item-
Provider classes. Instead, we would like to have a
more direct mechanisms to specify these customiza-
tions, and possibly grouped in one place, easier to
maintain. We will show our customization strategies
in Section 3.2.
Concerning the code generated for the model in-
terfaces and classes, instead of using this technique
for replacing generated code, we could use specific
annotation in the ecore metamodel so that we can also
specify the implementation of specific methods for
the classes of the metamodel.
However, this is not easily applicable to code
generated for the UI classes, thus one should use
the @generated mechanism described above for cus-
tomizing the generated editor.
Another problem with this @generated and
EMFComponents-FillingtheGapbetweenModelsandUI
35