New to Mendix? Read Kinetech's CEO Michael Guido's on 9 tips for getting started with Mendix.
Thanks to Mendix’s continued rapid growth (109% in the first half of 2013 alone), we are constantly training new folks on how to use the Mendix App Platform and its visual, model-driven development capabilities. As we work to continually increase the competency of our new customers, partners, and employees, I have seen a few reoccurring mistakes that beginners should avoid. In this post, I will outline nine pro tips to help beginners become better visual modelers with Mendix.
Please note: if you are a certified Mendix Engineer, you may want to scan the list of nine tips as a refresher. If you have not yet taken the Mendix Apprenticeship class, some of the concepts may not be familiar to you. In that case, bookmark this post and refer back to it afterwards!
1. Understand the Data Model or Question the Relationships
Teams work best when everyone is on the same page. More often than not, intellectual consensus on a specific design ensures that all teams understand the desired functionality as well as the real-world relationships the system is being designed to support. If you do not understand the data model or have questions, ask! Confusion only leads to sloppy modeling which, in turn, leads to rework. The whole point of having a visual model is to facilitate discussion (a picture is worth a thousand words) and increase understanding. As one of my mentors eloquently states, “Once you build the data model, the application practically builds itself!”
I cannot stress just how important this first tip truly is. Model mastery / comprehension will accelerate:
- Constructing sophisticated XPath Constraints
- Building reusable sub-flows
- Designing functional forms
2. Navigate Using the “Right-Click” Go to Form, Microflow, Entity (Data Model) or Find Usage
New Mendix Engineers have a tendency to use the navigation panel on the left to try to find their way around an application. As the application grows and the names of forms and microflows begin to look similar, they sometimes end up creating duplicate forms and flows that do essentially the same thing.
Using the right click to navigate is one of the most critical habits for Mendix beginners to adopt. It will help you increase comprehension of the data model (Go to Entity) and improve your knowledge of the flow of an application.
3. Use SubFlows / Reusability
If you are working on a team to develop an enterprise application, decide on some key naming standards up front and occasionally audit each other. This may seem a little harsh, but it really helps for large teams and projects. A few key things to discuss and agree upon are:
- When to create a Subflow. A good rule of thumb is as soon as you use something twice, create a Subflow. This will drastically improve maintenance and debugging, and reduce complexity / confusion.
- How to handle validation messages. This may have an impact down the line, particularly for Maintenance and Translation (for multi-lingual applications). For validation messages, I suggest creating subflows that take an input (or inputs) and return a string. This way, you can concatenate messages and reuse validations.
- How to structure Microflows. Again, this seems like a no-brainer, but developers’ styles vary. A simple agreement like, “The happy path of all Microflows should follow the horizontal (true), while any splits should divert to the vertical” will go a long way to making flows easier to understand.
In the microflows above, the orange “splits” differ in their outgoing sequence. In the top microflow, at the first split, a “true” result from the condition forces the flow up (this is technically not incorrect, but it is confusing for other users). The bottom flow uses a consistent structure with the previously agreed up structure (the happy path follows the horizontal).
4. Agree on Naming Conventions
The Mendix Apprentice training has some really good content on best practice naming of microflows. If your team has agreed on something more suitable for you, that is fine too! Just be consistent and audit each other’s work occasionally. The time spent doing this up front will save significant time down the road in maintenance and debugging. Here are a few conventions I like to use:
- Calc_DescribeMicroflow – I use this naming convention when I create a subFlow that will take an input Parameter(s) and return a value (object, or value). For example: Calc_SumTwoNumbers will take in two values, add them together, and return the sum.
- IVK_DescribeMicroflow – I use this naming convention when I am going to call a subFlow (like the one above) and I intend to commit the value. For example, IVK_SumTwoNumbers will pass in both parameters, call the Calc_SumTwoNumbers subFlow, and then commit the value.
- OCh_DescribeMicroflow – I use this naming convention when a user wants changes to be reflected after they change values on a form and they want to see the result refreshed upon committing the value to the database.
5. Use the Debugger
Using Mendix to visually model applications can be very exciting coming from the world of spaghetti code. With microflows, you can quickly and easily label and model the business logic of your application. However, as time goes on (or as you are completing a repetitive microflow), it’s sometimes easy to mislabel a split or retrieve. When this happens, your application may not perform as it appears. The tip here is to ensure you use the debugger to confirm the modeler is manipulating the same entities and attributes that your labels suggest it should. I typically setup my debugger like this:
Visual Debugging in Mendix. Left panel depicts - Input parameters /available attribute values for inspection (or confirmation), Middle Panel depicts - control in debugger panel (step into, step over, step out, continue), and Center Panel depicts - microflow with red highlighted subflow indicating where in the execution the application / debugger is.
6. Minimize Retrieves where Possible
Simple Data Model - Parent (1) to Child (Many)
Option 1: Incorrect Use of Retrieve
Option 2: Correctly Check if ASSOCIATION Exists before Performing Action.
7. XPath Constraints
8. Account for Null Values
Where the Create Variable above should actually have the first two empty checks before performing the actual calculation and returning the value.