EMF Client Platform: Make It Happen! Day 4

This part of the series describes how to replace the editor of the EMF Client platform.

“Make It Happen” is an example application we are using to present the features of the EMF Client Platform. On day 0, we created a simple model containing Tasks and Users. With this model, the EMF Client Platform has already provided a fully functioning application including a model explorer, an editor and the ability to share and version model entities (day 1). On day 2, we adapted the look of the elements, added custom icons and adapted the label. On day 3, we added a custom validation rule to our model. Violations of this rule are displayed in the UI, allowing the user to fix them in the editor:

Until now, we have used the reflective editor for every model element. The advantage of this is that the application remains independent of the model. The UI provided by the EMF Client Platform is robust against any change in the model. In a later state, once your model is more robust against further evolution, you might want to customize the editor depending on your model. There are two ways of doing this:

1. You can provide your own rendering engine to the existing editor. We will describe this feature soon.

2. You can replace the editor with a customized UI. This can be done step by step for specific model elements only. It provides complete freedom in creating a custom layout. The custom implementation is dependent on the custom model and therefore needs to be maintained manually.

Day 4: How To Replace the Editor

The EMF Client Platform allows you to replace the default editor with your own implementation. More precisely, it allows you to define the action to be executed when you double click on a model element. This allows you to open a custom editor, view or even execute something completely different. In the “Make It Happen” example application, we want to stick to the default editor for all model elements. However, to demonstrate the extensibility, we want to add a custom action to be executed when an element is doubled clicked on in the model explorer. On day 2, we added a new type of element to the tree of the model explorer; the email addresses of a user are displayed as its children. Since these tree nodes are not EObjects, the default editor cannot render them, therefore currently nothing happens if you double click on the email address nodes in the model explorer. In this tutorial, we describe how to influence this behavior.  In the example, we will send an email to the email address the user double clicks on.

Please use the links below to see all posts in this series:

Make It Happen! Day 0 and 1

Make It Happen! Day 2

Make It Happen! Day 3

Make It Happen! Day 4