Now that we’ve admitted to having a problem with the standardisation of complex validation messages and convention in general, its time to present a solution and perhaps a best practice as well. Having one to begin with is far better than retroactively fixing bad standards which is a costly and a painful exercise. Sometimes you don’t need a revolution to improve things, when things are in bad shape, all you need to do is to put it back in the right shape. in other words you don’t need a revolution, you need reformation.
The strategy I propose involves taking advantage of Non-persistent entities in Mendix introduced in version 4. We will also be taking advantage of calculated attributes. We will create an entity called ValidationMessage, which has 3 attributes:
- Message: This contains our validation string
- IsValid: A flag that EXPLICITLY tells if our validation is true or false
- HasMessage: Another flag that is the inverse of IsValid.
Your split could use either of these as “HasMessage->True” or “IsValid->True” which depends on how you want to state the happy-path along the horison of your flow.
Whats under the hood
Now lets look at a microflow created so that we can append strings to our validation message whenever we need. Its called AppendValidationString. All it does is change the ValidationMessage entity by appending the new validation string to the validation and trims blank spaces. You will find this microflow in the API folder:
Now you can decide how to condition the message. For instance, you might want to add text-bullets in-front of each line or format HTML.
An example of the outcome would be:
- Full name
When you display the message in a warning, you would prefix the validation with a leading statement if it contains bullet-points:
- Full name
String-ing together your validation message
Now your validation microflow would look something like this and will return a ValidationMessage entity instead of a String:
And on the microflow using your validation microflow, you will validate your Message explicitly as follows:
Now things are clearly defined and we remove confusion. Judge,which of these 2 expressions look better:
$ValidationMessage != empty and $ValidationMessage != ''
Not only is our validation split explicit, but you can find all your validation splits in your model using “Find usages” on the IsValid attribute or the ValidationMessage entity. You can even exchange the Split for a Rule and score extra Ninja-points for best practices. In my last big project, the model contained 3475 microflows. Just imagine yourself looking through that for consistency!
Now that you have a convention in place, your mind can rest at ease. And if you didn’t, sit back and enjoy the symphony of chaos and gradual destructionStay tuned for part 3 of V for Validation called Lost in translation where I augment the framework to deal with international validation messages. I will also do a video blogpost to conclude the series so you get a richer experience. The module will be made available in the Appstore and for download here.
Additional notes on convention
Large project best practices will be addressed in a later blog post, but I’m including a few footnotes on conventions from the validation module here, which wasn’t primarily the focus of the post but is still useful to know.
Notice in the microflow screenshots above that we chose to make validation message actions Orange so its clear when you open a microflow to spot the validation actions.
Looking at the module, consider the folder structure. The 2 folders “API” and “Domain Model”:
One contains Domain Model Entity-related microflows and another folder contains API microflows, intended for reuse by engineers. This helps identifying clearly which microflows are low-level plumbing and which ones are for public use.
Naming conventions schools of thought
There are different schools of thought when it comes to naming conventions. I’m not a big fan of Hungarian Notation and I favour longer descriptive names because its more explicit and makes your module descriptive. Maybe its not so much the Hungarian notation itself, rather the lack of description when relying too much on acronyms.
In my Domain Model, I have 3 microflows, 1 AfterCreate event handler and 2 Calculated attributes to handle the validation logic:
- AfterCreate_ValidationMessage: This just sets the starting message to a blank string ‘’ to avoid checking for an empty value
- Calculate_ValidationMessage_HasMessage: This simply tells me if there is something in the string
- Calculate_ValidationMessage_IsValid: This simply tells me if my validation as triggered feedback to the user
Note the naming convention of the virtual attributes. Instead of adopting Mendix’ VA_Attribute I prefer the format Calcualte_EntityName_AttributeName since its a calculated attribute called “Attribute” and not a stored one for “Entity”. This reads better and avoids duplication of microflow names. If 2 entities in the same module both have a similar calculated attributes, you won’t get away with VA_AttributeName format.