EMF Forms 1.4.0 Feature #1: Support for alternative UI Technologies

In this blog series, I describe the five most notable new features of EMF Forms 1.4.0. EMF Forms is a framework to efficiently develop form-based UIs based on a given data model. Please refer to this tutorial for an introduction to EMF Forms and to this post for an overview of the series.

As you might have noticed, it took me quite a while to post the last part of this series. In the meantime, EclipseCon Europe, the preparation of our Democamp and many new users of EMF Forms kept me pretty busy, so I am glad I finally found the time to present my favorite feature of release 1.4.0: Support for alternative UI technologies.

Have you wanted to be able to switch the UI to a different UI technology such as SWT, JavaFX, the browser or even a mobile device without re-developing all your forms? Do you see a risk in whether your UI technology of choice will be the right one for the next 10 years? Do you like EMF Forms but do not want to use SWT? This might be interesting for you then :-)

One big advantage of the model-based approach of EMF Forms is the independance of the UI toolkit. The UI itself is described in a view model, which is then interpreted by a rendering component. The approach and the EMF Forms architecture allows you to plug in different a renderer. In a simple case, you plug in renderers to adapt the way certain elements are rendered. However, you can also provide a complete renderer set, which uses a different UI technology. See this tutorial for details.

The default and reference renderer is still based on SWT:

EMF Forms also ships with all necessary adaptations to run on RAP and therefore bring your form-based UIs to the web:

With 1.4.0, we introduced the first beta version of a JavaFX renderer:

We are actively working on a renderer using AngularJS:

As well as a mobile renderer for iOS and Android using Tabris:

Finally, contributors are working on another web renderer based on Vaadin:

As you can see, the approach is really powerful when it comes to UI technology independence. This lowers the risk for a technology decision but also enables the parallel use of UI technologies for different use cases.

I have created a tutorial describing how to use the different available renderers.

Addtionally it is surprisingly low effort to implement a custom renderer for a new UI technology.

If you are interested in one of the renderers under development or want an evaluation or support to implement your custom renderer, please contact us. We also provide sponsored development and development support for these purposes.