Hello Paul,
In my year and a half of Mendix experience I've never come across a scenario where I had an action and an on-change microflow with the same microflow (logic). However, if I were to maintain an action and an on-change microflow with identical logic, I would probably insist on making a seperate ACT_ and OCH_ microflow, with a SUB_ microflow in both these microflows containing all the logic. I've always preferred to keep as much of the business logic (for example validation of actions) in SUB_ microflows to maintain a clear divide between the business logic and the UI actions. I hope this helps!
With kind regards,
Cas
Hi Paul,
I understand your jaw-dropping, but I am very happy with the conventions.
Naming microflows very descriptively allows you to understand what's inside without having to open them. This speeds up understanding your application's logic. With regards to the ‘fixing’ the purpose of the microflow, for me it makes me think about what the microflow should really do. For example, if I have an ACT microflow that executes a bunch of logic that I should use somewhere else (e.g. in an OCh), I should create a SUB for that bunch of logic.
It should definitely not discourage reusability, but it does encourage you to add that extra layer when logic is reused in different ways. This isn't weird to me, since you might also have slightly different parameters in those cases.