I would like to suggest a new Studio Pro feature to improve reusability of microflows. When using a (market)place module there are often scenarios where you want to extend the provided functionality. For example, you want to add attributes without changing the original module, so you create a specialization with the new attributes in your own custom module (as well as customized pages to show the attributes). However, at that time several microflows in the original module become useless, as they are based on the original module and do not ‘know’ your custom entity exists.
Reusability could (in my opinion) greatly be improved by introducing a new type of activity called ‘placeholder’
Suggested implementation
What this would solve
Example usages:
A marketplace module implements placeholders for object generation and for displaying pages. When calling the microflow in the core module, the ‘consumer’ can specify a custom microflow, generating the specialized object (if the consumer does not want to use this, the core microflow would check for an empty output parameter and creates the generalized object). Same for the “ACT_ShowAPageForTheObject” microflow: the consumer can provide custom logic for opening a page, and if not shows the generic page as contained in the module itself.
Another example: You are creating a module to implement a specific API. As published of the module, you define a placeholder for consumers of the module to write their own implementation/conversion into the app-specific domain model.
Any thoughts/remarks/alternatives are appreciated!
Regards, Joost
*edit: images would not show after saving, so uploaded them again
I do like the idea Joost! I think it would be powerful to make this available for mainly private modules (if not only) to keep things organized with a purpose. I can imagine that additional features like; 'generate placeholder page/microflow' would be powerful too. With a small wizard to point to the desired module and folder. The generated logic should contain the correct inputs and outputs, so it's easier to fill in the blanks. One step further, we could imagine that the generated placeholder logic contains some default logic too, as this is common to many modules. When importing such a module, Studio Pro must likely say, 'Hey, you need to generate the placeholder logic first because the action can't be empty.'
This just makes sense.
See also https://community.mendix.com/link/space/app-development/ideas/4890 for my other idea to improve reusability: Custom Event Handlers