Helping you drive digital innovation
Subscribe
RSS Feed of the Mendix Blog
Thanks for Subscribing

Keep an eye out for Mendix resources coming straight to your inbox.

Model-Driven Development: 9 Pro Tips for Getting Started with Mendix

on November 12, 2013

Share:

Editor’s note: In his latest post, Senior Consultant Michael Guido offers tips and tricks from the trenches to help beginners become proficient visual modelers 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.

Right Click – Go to Entity (Parent)

Right Click – Go to Entity (Parent)

Right Click – Find Usages

Right Click – Find Usages


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.

Mendix Tips 3
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:

Mendix Tips 5
The Buttons at the bottom (Step Into, Step Over, Step Out, and Continue) allow you to step systematically through your microflow.  The Red outline (currently around “Create Parent”) allow you to visualize where in the flow the Mendix is attempting to execute.  Finally, the variable(s) pane on the left panel allows you to see the actual Entity and Attributes.

Beginners tend to look at their microflows and confidently predict that their logic is sound without realizing the label is not a true indication of the underlying attribute.

6. Minimize Retrieves where Possible

Excessive retrieves can drastically reduce performance in large applications, because they can take up server capacity (especially when multiple users are accessing the application simultaneously).  Beginners will commonly use a retrieve then check if it is empty (for a GetOrCreate Subflow for example).  A faster and more efficient way to do this is simply to check if the association exists, then act accordingly.  Below is a simple data model and then two examples: the first showing a common “beginner” mistake and the second showing a more efficient retrieval.

Mendix Tips 6A

Simple Data Model

Option 1: Incorrect Use of Retrieve

Option 1: Incorrect Use of Retrieve

Option 2: Correct check if Association Exists

Option 2: Correct check if Association Exists

Both flows accomplish the exact same thing (either returning the Parent of the Child, if it exists, or creating a new one and associating it to the Child).

However, Option 2 is more efficient because the Engineer understands the Child can have only Parent (because of the data model); see tip 1!  Thus, if the association does not exist in Option 2 ($Child_1/MyFirstModule.Child_Parent = empty) , the engineer eliminates the retrieve and simply goes straight to Creating the $NewParent_1.  In complicated models with multiple layers of subflows, minimizing the retrieves will improve performance.

7. XPath Constraints

This one goes all the way back to tip number 1!  XPath constraints allow you to Constrain data based on the association with other tables.  In other words, think of an XPath constraint as a join between two tables.  In order to write XPath Constraints effectively, you should typically take the shortest possible path to the desired data to eliminate unnecessary joins.  When writing XPath constraints, you can only compare variables to the contents of an association or with the value of an attribute.  Furthermore, XPath constraints always consist of an odd number of elements. So [Parent_Child/Child = $Variable] is not possible but you can use: [Parent_Child = $Variable] or [Parent_Child/Child/id = $Variable] or [Parent_Child/Child/Name = $Variable/Name].

8. Account for Null Values

This tip sounds like a no brainer, but as a beginner, it can be easy to forget.  Anytime you are performing a calculation (with numbers, dates, etc.) always be sure to check for empty values before performing the calculation.  This is particularly important when using On Change microflows.  To reference the microflow above (Calc_SumTwoNumbers), the actual calculation you should use is:

Mendix Tips 8b

Where the Create Variable above should actually have the first two empty checks before performing the actual calculation and returning the value.

9. Annotate your work and test, test, test.

The last piece of advice applies to any software, and will always ring true.  Before launching an application, make sure to test your work thoroughly.  Automatically assume user will try to break your code model so attempt to make it as “iron-clad” as possible.  The only way to do this is to test thoroughly and repeatedly.

What’s your best advice for beginners to Mendix and model-driven development?  Do you have a favorite tip or trick that will help beginners get up to speed more quickly?  Please share them in the comments below!  Thanks for reading and happy modeling.

Subscribe to Our Blog

Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.

RSS Feed of the Mendix Blog
Michael Guido

About Michael Guido

A certified Mendix Engineer, Michael supported large customers, such as BDC, Liberty Mutual, and FCFCU, before launching Kinetech Cloud, an independent SaaS and consulting company and Silver Mendix Partner.

  • Savan Vyas

    Good article, really helpful stuff.

  • rsubhas

    Really good article. I just had a training and started using Mendix from past few weeks. I would like to know the pitfalls for the people who come from OOPS background (i.e. who talk and think about objects, inheritance and polymorphism) while designing data models. I designed data model with generalization of all my entities in one single entity so that I don’t specify all the attributes for each entity again and again. But I heard from expert and the trainer says that it slows down the performance. So, any tips how to decouple thinking from OOPS?

  • Pieter

    Its always nice to have a read on tips and tricks! However i do wonder why at step 6 you create a new parent even if the child already has one.

  • M_Guido

    Hi Pieter,
    First, thanks for your comment! In step 6, I am not creating An additional parent but rather the first and only parent. The check is to see if the Parent (that we tried to retrieve from the child by association) is empty. For some reason if the $Parent is empty that we tried to retrieve, we will create a NewParent and correctly set the association to the child.

    The benefit of this flow is that it can easily be reused and will never cause a null pointer (if the parent exists, we will just return it, in the case that it does not exist, we create it and correctly set the association.

    Let me know if that is still not clear, and thanks for reading!

  • M_Guido

    Thanks Savan! Obviously the Forum (https://mxforum.mendix.com/) is a great place if you are looking for more help or for a specific issue but stay tuned, all have some other content coming out shortly regarding best practices for PMs. Also, let me know if there are other topics you are interested in hearing more about…

  • M_Guido

    Hi, and thanks for the question. I also came from a Java, C# background and made the transition rather seamlessly. With Mendix, our goal is to make complex things seem simple so if you are familiar with Object Oriented Programming, your comprehension and understanding of Objects, Polymorphism, and inheritance will accelerate your ability to deliver sophisticated solutions with the Mendix platform (while keeping the data model).

    The largest “jump” in comprehension I see beginners struggling with are understanding the seemingly limitless use of microflows. Specifically, the concept of developing microflow services that can be used consistently throughout the application. Also, visually building loops in mendix when they would normally use for, while, and do while loops in more traditional programming languages are something beginners tend to struggle with.

    As for inheritance, there are situations where you have no other option but to use it. My advice would be to use it strategically and the performance of your application should not be affected significantly (i.e. if you need an entity to behave like a document (i.e. be able to easily create PDFs, Word Docs, etc) you have to inherit from the System.FileDocument class. Please note however, you should almost never modify entities in the System Domain Model as you could run into issue when upgrading from one version of Mendix to the next. As a general rule of thumb, I never go farther then two-levels of inheritance within a mendix model.

    Hope this helps!
    Michael

  • M_Guido

    Hi Pieter,

    You are correct, the picture was mislabeled, the corrected one is now up! Just as a side note, the way it was modeled, in the original (now replaced option 2), the retrieved $Parent, would end up losing a reference to that $Child_1 and $Child_1s association would be reset to $NewParent_2 (now removed from picture).

    Thus in any Data Grids or Nested Data Grids within a Data View, the application would no longer show (because it will not exist) an association to $Parent (as it was replaced by $NewParent_2). As the data model depicts, a Child can only be associated to 1 parent entity. Obviously this is not the desired result of the getOrCreateParent microflow so I have updated it accordingly. Nice catch Pieter.

  • Rik Dingemans

    Great article, Michael. One question: The calculation in tip #8 checks if the values in $Num1 and $Num2 equal empty. But in my opinion you should check if the values NOT equal empty, to result in a valid calculation. So there should be “!=” instead of “=”

    Am I correct? Thanks!

  • PieterSch

    How do you return a $Parent_1 that you didn’t retrieve? In the image I see no available object $Parent_1.