EMF Forms 1.7.0 Feature: Runtime View Model Migration

With Mars.1, we released EMF Forms 1.7.0. EMF Forms makes it really simple to create forms that edit your data, based on an EMF model. To get started with EMF Forms please refer to our tutorial.

In this post, we want to outline a new feature of the 1.7.0 release: Runtime migration of view models.

Short Story

In case we change the view model definition, we provide migration support to enable you to keep your existing view models up to date. This should be done in your development time, when switching to a new release. In 1.7.0, we added a fall-back enabling the migration also during runtime. Please see our migration guide for more details. However, runtime migration should be a fall back, we recommend to pro-actively migrate your view models.

Longer Story

The main concept of EMF Forms is a declarative language to describe form-based UIs, the View Model. It is simpler and more focused than programming UIs with a UI toolkit such as Swing, SWT, or even with HTML. See this blog post to learn more about the advantages of this approach. When using EMF Forms, the View Model becomes the central artifact to define a form-based UI, it therefore contains a lot of value. As a consequence, the View Model is expected to be a long living artifact. The View Model is even independent of UI technologies, it is translated by a UI Toolkit specific rendering component. Therefore, the View Model can even be re-used when migrating to a new UI technology, e.g. when migrating from a desktop to a browser application.

While the technology independent format provides advantages, we need to take special care of the View Model to enable its long-term maintenance. The technical basis is well-chosen for this requirement. The view model is defined in

However, even if EMF went away, your view models are not lost. Due to its declarative nature, it is easy to transform the view model in any other format, which has a comparable expressiveness. As an example, we have recently added an exporter to transform view models into a JSON format (see jsonforms.org). This enables view models to be used in pure web contexts and completely independant of EMF.

Another potential threat for the view model artifacts would be incompatibilities with new versions. This would mean an old View Model is not compatible with a new version renderer, provided by EMF Forms, by JSON Forms or custom renderer. To avoid this problem, in the past, we have dones two things. First, we design the view model in a very modular way making it easy to add new concepts without affecting the existing ones. This worked well, since in version 1.4.0, we managed to keep the number of relevant changes on the View Model down to three (see this tutorial). However, we also do not want to keep things in the View Model, which are not optimal. So some changes are unavoidable. For these cases, we provide migration support. This mechanism, supported by Edapt, will automatically migrate your view models to a new version and therefore ensure compatibility (see this blog post for more technical details). Migration is an explicit step, so, you need to trigger it when updating to a new version of EMF Forms (in case there are relevant changes).

In the past, if you did not migrate your view models, you may have received an error when starting an application. For this case, we added another safety net: Runtime View Model Migration. There is a new component, you can add to your runtime application. For every view model loaded, it checks the compatibility, and if necessary, migrates it on the fly. Please see our migration guide for more details. However, please note that Migrating View Model during runtime is not recommended as a regular practice. The runtime migration needs to take place on every application startup. This feature is intended to serve as a fallback only, if a legacy View Model was not migrated at development time and made its way to production code. So please migrate your view models proactively.