EMF Client Platform and EMF Forms on Eclipse 4 (e4)

With release 1.2.x, EMF Client Platform and EMF Forms officially support the Eclipse 4 Application Platform (e4). In fact, it has been possible since release 1.1.0 to develop e4 applications based on ECP and EMF Forms, but parts of the UI support were still bound to e3. In 1.2.x, we refactored these remaining pieces. Since we still support 3.x and will support it in the future, we needed to single-source the UI behavior. Because this might be interesting for other frameworks, too, I would like to go into a little more detail about this.

The simple part has been EMF Forms (if you do not know what EMF Forms is, please see eclipse.org). The framework is developed completely independently of 3.x or e4. The resulting form-based UIs can be embedded anywhere, as long as there is a parent of the respective UI technology (e.g., Composite for SWT, Pane for JavaFX).

So, there was no work to do here. The following screenshot shows EMF Forms embedded into an e4 application:

For ECP, the situation was a little different. ECP provides re-usable components to create UIs for EMF data model instances; EMF Forms is one of these components. All these single components of ECP were also independent from 3.x or e4. When we designed this, e4 was already around so we had already split the generic and the 3.x specific parts. This is something I would recommend in any case, even if you are not considering moving to e4 at all. It just makes your design cleaner and avoids the unnecessary dependency on Eclipse 3.x. For example, if you want to trigger a delete of an element from within a context menu in e3, you will have contributions as extensions (command, handler and item) and the implementation of the handler. All these things are 3.x dependent. But the actual implementation of the behavior in most cases does not need to be. The following overview shows the scheme we typically follow. Most important: Wherever applicable, features are implemented in an independent bundle (UI common). This is where 90% of your code should go.

The 3.x UI and e4 UI bundles contain very small classes that are mainly adapters from the common UI bundle to e4 and 3.x. They abstract any concept of 3.x or e4. A good example is a delete action of a certain model element (in the case of ECP, an EObject). The actual feature is implemented in the common bundle and provides an API such as:

ECPHandlerHelper.delete(EObject eObject);

The e3 Handler will need to unwrap the selection, such as:

ISelection selection = HandlerUtil.getSelection(event);
if(selection instanceof IStructuredSelection)
{
…
}

and so on. At the end, it will call the common part with the unwrapped selection. The e4 Handler is much simpler, e.g.,

@Execute
public void execute(EObject eObject){
    ECPHandlerHelper.delete(EObject eObject) ;

}

In Luna, it will be possible to use e4 views in 3.x applications, so at least for views, the two different wrappers would not be necessary anymore. You could also decide not to abstract from Dependency Injection and use the DI wrapper, as described in this tutorial. However, as a framework, we would like to keep backwards compatibility to at least one previous version of Eclipse. For custom projects with a fixed target platform, this is more of an option.

As shown in the previous diagram, we also separate the implementation of the handler wrapper (same applies for views) from their integration into an application in 3.x from their registration using the corresponding extension point. We actually already did that on 3.x as it provided much more flexibility to users of the framework. It is their decision whether they want to use all registrations or manually register only a few of them. This avoids unwanted menu entries or views in the workbench.

Finally, ECP also provides a demo application including a ready-to-use integration of views and handlers. This part obviously has some dependencies on 3.x. Since this part cannot be simply single sourced, with 1.2 we define an e4 demo application that integrates all views, too.