Expert Validations in Mendix
From Best Practice to Expert Practice
While developing Mendix apps, at some point in time, any developer is faced with this problem: user input needs to be validated in order to keep the database clean. Mendix’ Academy teaches us how to build these validations in an efficient and performant way. However, the effort that goes into maintaining these validations can be greatly reduced when applying an expert pattern that I would like to share with you in this blog.
Let’s start from the current Mendix best practice with a use case, which I will enhance in steps to finally showcase the expert pattern. Use case: within a “User” Entity, 4 string attributes need to be validated according to the design below, before committing to the database.
Following current best practice, a single long Microflow would be built, that would contain one Decision for each validation requirement. It would probably look something like this.
In this Microflow, only two attributes (FirstName & LastName) are validated in only four ways: required, MinLength, MaxLength and NoWhiteSpace. However, the Microflow is already becoming very difficult to read and is bloated, even though we have only implemented 8 of the 21 Decisions necessary, according to the requirements table above.
Trimming, Rules, and VAL_Microflow
The first way to optimise this flow, is by using a trim() on the attributes at the beginning of the flow. Likewise, the Decision Expressions will become better legible, as we don’t have to apply the trim() function in each one. An added benefit is that the trim() function only has to be computed once, which increases the computing speed of the entire flow.
Secondly, we can employ a Rule for Expressions that are used in more than one Decision; likewise we can maintain that condition in one place. Below is an example of Rule_String_NotEmpty, which can be used to check if LastName, Interfix, FirstName, or even Email have been filled, as all these are string attributes.
Thirdly, we will move the validation of the Entity, into a (SUB) VAL_Microflow, solely responsible for validating the User. The result of the VAL flow is returned to the super flow with an isValid boolean. Let’s also mark this VAL flow in green.
What is immediately obvious, is that this Microflow has become legible again. Also mark that the responsibility of this Microflow is now also much clearer, namely, committing User.
The VAL_User flow (below) also becomes easier to read, and it only has one responsibility: validating the User Entity.
Why Is My Flow Still a Mess?!
Even though this flow has been cleaned up significantly, it is still bloated and cluttered. Moreover, only 8 out of the required 21 checks have been done. Imagine having them all here!!
Let’s engage in a thought experiment! Let’s assume that there are more Entities in our project with the same attributes. For example, imagine a large Mendix application in which an anonymous user registers for the app using a non-persistable Registration Entity in one place, while using the persistable User Entity in other situations. Both Entities contain the same attributes (FirstName, Interfix, LastName, Email) and the same validation rules should apply to them. We are now faced with an even more complex redundancy issue: if a validation for an attribute has to be changed, it has to be tackled in each VAL_Entity Sub Microflow, which entails a lot of repetitive work.
For a recent project, we had six such Entities, containing similar attributes across two applications. Our team had worked on these validations according to Mendix’ guidelines, yet each time the business team added a requirement, we had to painstakingly go through each of these validations manually in order to implement the change. This was an inefficient, error-prone and time-consuming process that needed urgent tackling: the solution is to validate at the (primitive) attribute level.
Validating Primitive Attributes
In the validation requirements table above, it is visible that the same requirements apply to FirstName, LastName and Interfix. Furthermore, all of these attributes are of the string type. It would be logical to create a single VAL_String_FirstLastNameInterfix Sub Microflow. However, as the input variable is now a String and not an Entity, we can no longer use Validation Feedback Activities in this flow.
At the beginning, an empty String ‘ValidationMessage’ Variable is created with a value of ‘’. Whenever the input variable fails in a Decision, the ValidationMessage is changed or added to, as is shown in the annotations. At the end of the flow, the ValidationMessage is returned.
In the super flow, we can now compare the ValidationMessage that is returned in a Decision. If it is still the same as the initial value (‘’), we have a valid attribute. If not, we can set the ValidationMessage as a parameter to the Validation Feedback activity.
The validation flow itself is now very legible, and responsibilities are much more clearly delineated. We have reduced the number of Decisions and Activities in this whole VAL_User Microflow (including subs) from 25 to just 18 (30% reduction). Additionally, we can now use the same Sub Microflow for Interfix, with just 4 extra Decisions and Activities, which would have cost us 8 using the old pattern. It is apparent that as validation complexity increases, this pattern will save the developer more and more time, as compared to the existing best practice. An added benefit, is that it is now possible to provide the user stacked validation messages per attribute (e.g. No white space, minimum length), where in the old pattern it is only possible to one type of feedback on an attribute.
Concluding
Apart from improved legibility and clearly-delineated responsibilities, it is now also possible to maintain a validation at attribute level for a single application in one place, in stead of in multiple. Hence, this is a much more robust validation pattern.
Want to go even further? Create an enumeration Enum_ValidationMessages and store all your validation messages in one place. Subsequently, call on each of these enumerations with “getCaption(Module.Enum_ValidationMessage.Required)”.
Are you interested in learning even more about Validations? Feel free to reach out at any time at wouter.penris@ordina.nl
Read more
#About: Wouter Penris
Wouter is a senior (lead) Mendix Software Engineer with a background in education (English & Music) and in music (Jazz Vocals & piano); a multi-potentialite. Where as a teacher he spent years perfecting the art of instructing his students as simply and understandably as possible, he now immensely enjoys using this same skill to build high-tech products with an intuitive and easily-understandably Ux. He is a highly creative problem solver, in which he blends research, technology and aesthetics into actual business value and advice. Wouter is a communicator at heart and especially enjoys working with international clients due to his background in English.
From the Publisher -
If you enjoyed this article you can find more like it at our Medium page. For great videos and live sessions, you can go to MxLive or our community Youtube page.
For the makers looking to get started, you can sign up for a free account, and get instant access to learning with our Academy.
Interested in getting more involved with our community? You can join us in our Slack community channel or for those who want to be more involved, look into joining one of our Meet ups.
