EMF Dos and Don´ts #10

EMF is a very powerful framework and with power comes…responsibility. You can achieve great things with a minimum of effort using EMF, but if something goes wrong, you can also spend hours trying to find out why. This blog post is part of a series on things you should do and things you should not do when using EMF. You can use the link to the series pilot to navigate to the start and the link below to navigate to the next blog once it is published.

EMF Dos #10: Use EMF ComposedAdapterFactory

In my previous blog post, I discussed AdapterFactoryLabelProvider and AdapterFactoryContentProvider, which can be used to provide labels and children for your entities in viewers. Both require an AdapterFactory in their constructors that will be used to retrieve the actual ItemProviders and their entity-specific implementation.

If you pass in the AdapterFactory of a specific model, the provider will only be able to provide labels for entities of the given model. However, viewers often need to display entities of multiple models. Of course, there is a solution to this with EMF: ComposedAdapterFactory.

A ComposedAdapterFactory is a composition of AdapterFactories, as the name implies. You can construct it with a collection of AdapterFactories, and it will delegate calls to adapt() to the resepective AdapterFactory based on the entity type. If you want to display multiple models in one viewer, you just combine all the models’ AdapterFactories into one ComposedAdapterFactory and pass it to the AdapterFactoryLabelProvider and AdapterFactoryContentProvider.

If you do not want to restrict your viewer to specific models but want to use all models available in your current target platform, you can pass in ComposedAdapterFactory.Descriptor.Registry.INSTANCE, which is the registry of all available AdapterFactories. By default, the  AdapterFactory of a generated Edit-Plugin is registered via the org.eclipse.emf.edit.itemProviderAdapterFactories extension point and thereby added to the aforementioned registry.

If the AdapterFactoryLabelProvider/AdapterFactoryContentProvider and the ComposedAdapterFactory are based on the registry, your viewers can be fully decoupled from the actual models they display while still providing customized icons, labels and content.

The next blog is the series finale with links to all previous posts.