Empty Strings in Mendix
Imagine a form with 3 String attributes/fields. Before submission, the object has to be validated. Over the years I have seen a multitude of ways how developers check that Strings are filled, but there is a best practice that many do not seem to know about. Let me provide you with that best practice first, and subsequently offer you the proof.
trim($Object/StringAttribute) != '' //best practice!!
You might wonder — “Hey! This guy is not doing an empty check first!” You are correct.
$Object/StringAttribute != empty
and
trim($Object/StringAttribute) != '' //less efficient practice!!It is not necessary to do this, and this article will explain why.
Let’s explore together in a test project, built in Mendix 10.6.1, based on the blank web app template. I have added an entity MyForm to the Domain, with three StringAttributes, and subsequently added overview pages and connected them to the home page. Skip the next image if you know how to do this ;-).
Subsequently, let’s open the MyForm_NewEdit page, right-click on the Save button, and generate a validation Microflow. Mind that when auto-generating empty checks for String attributes, Mendix will automatically use the best-practice expression mentioned above.
Next, let’s try to explore exactly what happens in the most common types of empty checks — mind that the first two are explicitly wrong (partial), but they will help us explore what goes on when debugging later on:
$MyForm/StringAttribute1 != empty //first check for StringAttribute 1
$MyForm/StringAttribute1 != '' //second check for StringAttribute 1
trim($MyForm/StringAttribute2) != '' //for StringAttribute 2When modeled, the validation flow will look like this:
Now 1) let’s run the app and add a breakpoint to the first activity, like above, 2) create a new MyForm, and 3) trigger the validation. The result is the debug session visible below:
Debug Walkthrough: as we haven’t touched our form yet, all three attributes in the MyForm object are initially shown to be empty. Decision 1 (leftmost) is therefore true (goes to the right), and decision 2 is not (empty is not equal to ‘’). Decision 3 (rightmost) goes down, but the question is why? When we check the object a final time, we do not see any change.
This is because the check that is done with trim() does not work on the actual value in MyForm/StringAttribute2 visible in the debugger, but on a copy that is out of scope. However, we can visualize it easily, by adding a create string variable activity before decision 3 and filling it with empty first, then changing it to the trimmed StringAttribute2. Let’s trigger the breakpoint again:
Debug Walkthrough: initially, we see that indeed the $TrimStringAttribute2 is empty. The result of the trim(empty) activity must therefore be an initialized String ‘’, which is indeed visible when we look at the value after the change.
All that being said, one might wonder if there are differences in behaviour between Microflows (i.e. server logic in Java) and Nanoflows (i.e. client logic in JavaScript). After converting both Microflows into Nanoflows (Read client JavaScript), connecting the new logic, and firing the form, this is the result:
Debug Walkthrough: interestingly and apparently, in a Nanoflow, form String fields/attributes automatically get an initialized String as a basic value, which is visible in the first part of the walkthrough. Then, it seems that comparing $MyForm/StringAttribute1 with value ‘’ against empty results in a true value now. In the end, it is visible that trim() initializes from empty to ‘’, just as is the case in Microflows.
Concluding, in Mendix trim() initializes empty strings into a String with value = ‘’ regardless of flow type(Micro/Nano). However, you may still wonder how this knowledge can serve you best, as a developer. In my opinion, it all boils down to two things:
- Readability — shorter expressions are simpler.
- Processing efficiency: the shorter you formulate your expressions, the simpler the eventual byte code that is interpreted by the processor; in other words, we can speed up our apps by just using trim() instead of first checking if a string is empty, and subsequently checking whether the string is not equal to ‘’.
A final note is that trimming is a best practice on string attributes anyway. Consequently, there is no use at all to first do an empty check.
Do you want to make your validations even more efficient? Check out my other articles below ;-)
#About: Wouter Penris
Wouter is a (lead) Mendix Software Engineer (Expert/MVP/Trainer) 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. Wouter currently works as Senior Principal Expert in Mendix at Ordina.
Ordina promo, January 2024 — www.ordina.nl
Read more from Wouter
From the Publisher -
Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.
For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.
Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!
