Question

More posts about how Mendix actually works

11

I saw Bas' blogpost about the Mendix microflow engine and I liked this very much. Sometimes it helps how things in Mendix work for Mendix engineers like us. Not everything, but especially when you build complex flows or experience issues with microflows which are acting different than you expected. I would really appreciate it when Mendix publishes more posts like these to help the community. I enumerated some suggestions below: How does caching of variables work in microflows? Explanation of executions order of actions in a microflow. Are client actions always executed last in a flow? Is every xpath retrieve directly triggered to the database or mixed with other retrieves? I know some things are secret and not meant to share with everyone, but it would be really nice to know more about 'how mendix works'. Anyone with more suggestions or comments?

asked 2013-10-21

Samet Kaya

1 answers

Sebastiaan van den Broek · Accepted Answer · 2013-10-23

I can't think of any examples where the (functional) workings of the platform are secret :) I'm happy to write some more blog posts about the inner workings of Mendix and in fact I have at least 2 topics that I want to cover already and many of my colleagues have some ideas too.

To give you some quick answers:

Client actions are executed in the order they appear in the microflow, but feedback to the client is sent when the server is done executing the microflow, along with the rest of the results. This means that things like showing messages will appear to be done at the end, because only then the client gets told about it. But if there is an expression in your 'show message' action then it will be rendered where you would expect it.

XPath retrieves are always executed on the database without merging existing cached data. There are other types of retrieves that do merge data though, like when you retrieve over an association.