EMF Forms 1.14.0 Feature: Enhanced Input Validation

EMF Forms makes it simple to create forms which edit your data based on an EMF model. To get started with EMF Forms please refer to our tutorial. In this post, we would like to outline a new feature in the 1.13.0 release: The extended input validation. With this, you can forbid illegal values from being entered into a form and can support the user, with live validation while entering data.

One of the advantages of using EMF Forms has always been that it provides validation features straight out of the box. For the validation, EMF Forms mainly relies on the underlying data model. As an example, the following data model defines two mandatory attributes (lastName and email).

In the rendered UI, those fields are automatically marked as mandatory (by default with an “*”) and a validation error is shown if the fields are not filled out.

By adding custom data types, EMF also allows you to define more complex constraints. As an example, we might want to confirm whether the Email field contains a valid email address. Therefore we would define a corresponding data type inherited from String, which defines an additional pattern (see below).

As EMF generated validators also for those patterns, EMF Forms would validate this constraint, too. The following screenshot shows how an invalid email address, which does not correspond with this pattern, would trigger a validation error in the UI.

As you can see, EMF Forms completely facilitates all constraints given in the model. This is very useful because it avoids duplicate specification of those constraints within the UI code.

However, in the current scenario, it would first allow the user to enter invalid Strings. This is because the validation is currently only triggered when the data binding is triggered. Therefore, if you would like a control which only allows entering legal characters, you would have to create a custom control and deal with “verify listeners”. At least until EMF Forms 1.14.0, which now also supports this out of the box!

The solution is very simple, all default controls use a verify listener to validate input immediately. To keep the separation of the actual validation constraints from the UI code, the verify listener calls a service, called “PreSetValidationService”. This occurs before any character is accepted into the control, therefore, this mechanism efficiently allows you to restrict the user’s input. Of course, you can implement the PreSetValidation service however you’d like, but EMF Forms ships a default implementation, which you can simply add to your run configuration:

The default implementation validates any input against the defined data type in the EMF model. That means, if you already have defined the expected input in your model (e.g. by using regex pattern), you literally do not need to do anything on the UI site anymore. The default controls will no longer allow the input of any illegal values.

While this works great for many simple data types (e.g. Strings with limited allowed characters), it fails for more complex constraints. In the example above, we have defined a regex for a valid email address. If we would validate this for every character that the user enters, we would actually not allow the user to enter anything, because it is not possible to enter a valid email address with only one keystroke (except copy paste). Still we would like to restrict the characters, which can be entered to the legal once.

To solve this issue, the EMF Forms “PreSetValidationService” will optionally validate against a second pattern, which defines a less strict constraint. The key in the Ecore model for this is “loosePattern”. If you specify “loosePattern”, the key entries in the respective field, will be validated against this. However, the regular pattern will still be validated with only message. The following example specifies a “loosePattern” for the Email example:

The nice thing about having the attribute constraints directly in the model is that you can reuse them at any place in your system. As an example, you can validate input values retrieved from an external service. In a different example, there might be another place in your application where you allow the user to enter this value. The following screenshot shows the same attribute “Email” in a table. Since the EMF Forms cell renderer is using the same validation service, the defined constraints are automatically valid.

In a third example, you might also consider Copy/Paste. The default Copy/Paste feature of EMF Forms validates values, before they get pasted. Therefore, users cannot even past illegal values into tables (as shown below).

As for all EMF Forms features, the new validation service is of course adaptable to custom requirements. If there are any features you miss or ways you wish to adapt it, please provide feedback by submitting bugs or feature requests or contact us if you are interested in enhancements or support.