Since joining the Mendix team, I’ve seen a number of common mistakes that our customers make when they are new to visual modeling. In this blog post, I’ll highlight five of these mistakes and illustrate how you can avoid similar issues in your own development efforts.
1. You are refreshing and committing everything
Often, new platform users are either over-eager or unconcerned with how often they commit and refresh objects into the database. However, it is important to refresh and commit at the right times. To understand why this is an issue, let’s look at a couple of examples.
Here is a simple example of a common mistake that users make when creating a new course object:
Image 1: Microflow that creates a new course entity and passes it to the Course_NewEdit pages
Based on the logic above, if a user hits cancel in the new course page, the person will end up with a blank course record in your datagrid. You are persisting an object to the database when you hit the new button instead of save. You should only commit when you want to save an object to the database. Think about when you need to create a new database record and if it it’s necessary to persist the object in the database.
Here is an example of not refreshing appropriately:
Image 2: The non-proper delete button is NOT refreshing on delete.
In this instance, when a user deletes an object, they will still see that record. This happens because you need to refresh the client to reflect the latest changes to the database. This does not mean that you need to go and over-refresh on everything. Just ask yourself, “when is it necessary to update the client and refresh objects?”
2. Your XPath constraints and retrievals are inefficient
Inefficient retrievals on Microflows or on the UI can cause performance problems. You can learn more about how to structure efficient XPath constraints in this post focused on performance, or in this reference guide document.
Think of XPath constraints as conditionals. From there, you are just filtering your data to display or retrieve the necessary information. Keep them simple and if you need to complicate them, use the resources above to do it right.
3. You forgot to add empty checks
Have your users seen the error below before? There are a variety of errors that may come up, but often these errors relate to empty checks (or the omission of these checks). Remember, it’s important to add empty checks whenever you reuse objects within your Microflow.
For example, if you receive this error, run a quick analysis on your logs (or even the Mendix console). In this instance, the error relates to the IVK_CommitSubscription Microflow, specifically the ‘Person’ object cannot be null.
As mentioned above, this often happens because you forgot to add an empty check somewhere in your Microflow logic. And if you look at the guilty Microflow, you’ll notice that we change the person object. When a user creates a new subscription, he or she might forget to select a person. In that instance, you need to add an empty check.
4. You forgot you can’t divide by zero.
Similarly to empty checks, if you are building applications where you need to add calculations, it’s always a good idea to add a check if you are dividing by 0. The user will see the same error as the empty check. However, in the logs you’ll see a ‘Failed to Evaluate’ expression error. My coworker Adam elaborates on more common runtime errors in his blog post here.
5. Your security isn’t actually secure enough
Don’t just select all user roles for access to every page or Microflow. Take the time to select the right roles for the right purposes. For example, if you get an error message (like the one below), your instinct may be to quickly remove the problem by selecting all user roles for access to all components. However, this instinct is wrong and exposes your application to more risk.
Be wary of how you implement security and limit access to your Microflows. For more security details and best practices check out this how to.