Our goal? Making
complex simple

11 January 2017

From building applications with PHP to modeling them using Mendix

Pim van der Noll
Chief Technology Officer

Here’s how I experienced my first two months.

Recently, Appronto gave me the opportunity to learn how to create business applications using Mendix. The platform was entirely new to me, but with my background in PHP I had a basic understanding of logic functions and architecture, which I hoped would aid me in making the switch. With that in mind I happily accepted the opportunity that Appronto had provided me and I was looking forward to the challenge of learning how to rapidly model applications in a low code platform.
At the time of writing this article I can say that the transition from programming to modeling went fairly well, but there were a few pieces of the puzzle that (at least for me) took some time to fall into place and in hindsight were pretty important. In this article I will highlight these epiphanies, which immediately clarified a few issues that I had encountered in earlier days and weeks before. Perhaps this will even answer some questions that other programmers who are interested in making the switch to Mendix may have.
I would advise you to at least check out the first free course that Mendix offers on their website . This will give you an understanding of the domain model (a visual presentation of the structure of your database, with entities as the tables) and how you can retrieve, change and store objects (like the rows in a table).
Also note that I am a Mendix beginner, so there may be more ways to solve a particular case than the ones I will mention in this article.

Microflow parameters and the end event.

As a developer I was used to store values in variables and sessions when transferring data from one page to another. In the modeler practically everything is represented by visual elements and I was trying to figure out which element(s) I needed to recreate that same sort of mechanism to pass data. Most of the activities within a microflow are pretty straightforward: retrieve an object (or a list of objects), do something with it and show a page (this is a very simple example). What I didn’t really understand was where the parameters that are shown within a microflow were defined or how you could pass a certain object (or multiple objects of different types) to “remember” for future reference.
After exploring an existing application for a while and receiving help from colleagues I learned that parameters can be sent to a microflow in several ways:

  • From a parent widget (like a listview or datagrid). Take a look at the following image.

    This is a datagrid that shows all the objects of an entity called “Employees” (with just one attribute: “Name”). When you select “Bernie” and click on “Microflow action” the parameter of that microflow will be that specific object that has “Name” = ‘Bernie’.
  • From another microflow: Inside a microflow you can call another existing microflow (they are generally called a “subflow”).

It is possible to pass any data type to that subflow that is available in the main microflow.
Now that parameters were clear to me, the next question I had was about the end event. All microflows have one start point and at least one end event. In most microflows that I studied there were simply end events with no label or text. They had parameters, activities and eventually opened a specific page, displayed a message or changed/committed an object and finally the microflow ended. However, some other microflows contained end events with captions like “List of Employees” or a Boolean value. Hurray, another puzzle piece fell into place: the return value!
When you want to retrieve a single object, but it takes 12 activities to get the desired object, it will clutter your microflow and have a negative impact on the readability. Instead, you can set up a subflow to retrieve this object and have the subflow return this object for you to the main microflow. The returning of objects, lists, Booleans (and more) is not only useful in subflows, but can also be used in microflows that act as a data source for a widget (like a data grid or list view).
Once I fully understood the input and output of microflows, reading existing ones was a lot easier and I was able to create new microflows from scratch for functionalities I wanted to implement, without needing much help.


When I first sat down with one of my Appronto colleagues, I noticed how quickly he worked and was trying to understand how he could show attributes from several different entities in one data grid (or even a page). I had studied the domain model the day before and had seen the associations between entities, but hadn’t fully grasped the meaning of those arrows and/or lines.
I won’t go into detail on these associations, because Mendix has enough documentation about this topic. Dragging attributes from different entities to a datagrid (from the connector tool) is relatively easy when you understand the connection(s) between the entities. The real eye opener for me was the use of data views to set the context to a specific entity (even if the caller of the page is an entity from an entirely different module) and then use the connector tool to place attributes you want to show on the page you are building.
Another thing I was struggling with at first was the use of these associations with an XPath expression. Especially when you follow several associations to get to the entity you want, the expression can become rather long. It helps to view the domain model while setting up these tricky XPath expressions, at least until you know the associations by heart.


While I was working on a new project, I asked available Appronto colleagues questions about how to best set up a database retrieve and often saw them use the token [%CurrentObject%] in the resulting XPath expression. When working with a data grid, that seemed pretty obvious: the selected object in that particular data grid is the current object (also see the first image). I did scratch my head a little when I also saw the same token being used not with a data grid as source, but within a data view. Luckily I soon learned that the direct “parent” of the widget you are working with is considered the current object.

Let’s go with another example:

  • We have two entities: Employee and Shoe (with string attribute color).
  • We’ll use a list view to show all employees and inside it another list view that shows all shoes (of that employee) that are not the color blue.

Ideally, we would want to use the association between the two entities to fill the nested list view, but then it would also show any blue shoes an employee may own. Because of this color constraint, we’ll need to use an XPath expression and this is where the token [%CurrentObject%] will play its part.
The resulting expression is as follows:

[MyFirstModule.Shoe_Employee = ‘[%CurrentObject%]’]
[Color != ‘Blue’]

The [%CurrentObject%] token in this expression is the Employee object from the “parent” list view. This will retrieve the shoe objects that are associated to an employee (line 1), but excludes those with color attribute “blue” (line 2).

These eureka-moments really helped me develop my skills and I’m still learning new things every day. If you want to meet the heroes who taught me all I now know about Mendix, check out our website and keep an eye out for our coming events!