Build custom validation messages

It has been a while I've added a new post. I've been moving to a new house. Some weeks later I've been come a father of a beautiful boy. So I hope you will forgive me for the late post.  That being said, let's get back to Mendix and build great apps. Off course I will build mine examples in Mendix 5.

The consistency of your data is of great importance of your business processes. If a part of data isn't correct, it can come corrupt with all consequences. On the other hand you want to use conditional visibility in your pages. The user must only see the fields what he needs to fill in. 

With Mendix you can add default validation checks on fields. Those only work when you don't use conditional visibility. When you set the property 'required' on a field that is placed on a row that is conditional visible, Mendix will generate the error: "Widget may not be required if the containing table row is conditionally visible." To implement validation checks on pages that contain conditional visibility it must be done with microflows.

In this example I use a page to edit a product: Product_NewEdit. The product can be of two types: Stockitem and Service. Based on that selection the user needs to fill in other types of data. The save of the product is handled by a microflow. The best practice to implement validation is the usage of a sub-microflow (a microflow that is called by a microflow). 

I create one microflow to validate a product: "SF_Product_Validation" and let the micrflow return a boolean: valid or not. The best way to start is to make a boolean variable that will used as the return value of the microflow. The boolean start with the value "true", we assume that the user gives the right information. Along the way of the microflow each attribute is checked and according how the conditional visibility is build in the page, the visible attributes are checked.

But why the use of a sub-microflow? To create an easier way for maintenance and possibility for unit testing. The best way to build microflows is by creating them in single functions, just like programming for example in Java. Microflows become testable for example unit testing.

Autocommit in microflows

At my first post I discussed a custom constrained by, by using a Microflow as a datasource. In the example I used an Order management and created a new "Orderline". I want to go on this example and discuss how Mendix works with a phenomenon "Autocommit". 

I'm going to save the new "OrderLine" with a Microflow trigger on the Form "OrderLine_NewEdit". Because it is a Microflow, it will not trigger the standard textbox validations. I have to build the validation myself. When the "OrderLine" is valid, I retrieve the "Order" from the association and calculate the total order price. Then the "OrderLine" is committed and the Form is closed.

When I debug the Microflow and look at the state of each object before and after committing the "OrderLine", something occurs. In the first step the "Order" as the "OrderLine" has the state "instantiated". The second step the "OrderLine" is committed to the database and gets the state "normal". The "Order" however has the state "autocommitted".

When the "OrderLine" is committed to the database, the association to the "Order" is also committed. In the database it isn't possible to refer to an object that doesn't exist. So Mendix inserts the "Order" and gives it the state "autocommitted". Based on this Mendix knows that cancelling the object must lead to a delete in the database, because it was't committed explicit by any logic.

• Instantiated: A new object that is only present in the application memory.
• Normal: An object that is present in the database.
• Autocommitted: An object inserted in the database by an association.

Get started with Mendix

Mendix documentation