EMF Forms 1.8.0 Feature: New Group Rendering Options

With Mars.2, we released EMF Forms 1.8.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 wish to outline an important enhancement for rendering group elements in forms, which allows you to create form-based UIs even more efficiently.

The core of EMF Forms is the so-called view model, which essentially describes how a custom form-based UI should look. “Group” is one of the most frequently used layout elements in EMF Forms. This allows you to contain any view element, such as controls or other containers, and therefore, enables you to structure a form. The element group is very flexible, it does not directly imply a certain way of being rendered. The standard EMF Forms renderer will render a group as an SWT group:


However it is pretty common to provide custom renderers. This allows you to change the way groups are visualized in your custom product. The benefit is that you do not have to adapt your view models in any way, you just need to provide another renderer. As an example, groups can also be rendered as a Nebula PGroup and therefore make it collapsible:


From various customer projects, we have learned that making a group collapsible is a fairly common need. To free adopters from the need to always implement a custom renderer, we have added this as an option the view model itself. Therefore for every group you can specifically configure its collapsibility. If you open a group within your view model, you can change the “Group Type” to “Collapsible”. Additionally, you can then set the initial collapsed state. The EMF Forms default renderer will then render it like this, using an SWT ExpandBar:


Another common issue with groups was that they are independent elements, which are also rendered independently. As this makes sense from a conceptional point of view, it sometimes produced unexpected results when it come to layouting. The following screenshot shows two groups below each other. As you can see, the layout is calculated independently for both groups, therefore, the controls are not aligned.


As this behavior is fine in some use cases, some users would expect the alignment. In this case, the renderer of the group would have to embed itself into a parent GridLayout, which is calculated and rendered for both groups together. This is now also supported by the EMF Forms default renderer. If you configure the “Group Type” to “Embedded”, the renderer will not create independent Grids for every group, but rather embed them, producing a more homogenous layout:


Of course there are many more possible adaptations available for group and other elements. To keep the view model language simple, we try to only add options, which are commonly used across projects. However, by enhancing the existing renderers, all types of customizations are possible. If you miss any feature or ways to adapt it, please provide feedback by submitting bugs or feature requests or contact us if you are interested in enhancements or support.