Prefixing Microflow names?

0
Hi, I’m just working through the training for building apps,  Just got to the bit that recommends prefixing the microflows with the type of action calling it.  Jaw dropped a bit, I feel like the 90’s are calling and want their coding conventions back.  Do people do this, has anyone not followed this convention and how has that worked out for you?   I guess my biggest concern is that it implies that code reuse could be quite low if the microflow has to know about the context in which it is called.   I’ve not used it enough to see if microflows can be shared amongst two or more things that the training recommends a specific prefix for (i..e an ACTion and a On CHange event) and what prefix it would recommend in that instance (please don’t let it be ACTOCH_) Thanks,  – Paul
asked
2 answers
2

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

answered
1

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.

answered