New functionality “FastCasting” under Mendix modeler
Understanding the need
The goal of this new feature is to simplify the process of casting legacy objects by eliminating the intermediate split step. This would increase efficiency and readability in microflows.
Proposed operation of "FastCasting"
- Identification of target type: When creating an association or expression, the user would explicitly specify the type to which they wish to cast the object.
- Checking for inheritance: Mendix would check if the target type is a descendant of the source type.
- Automatic Cast: If the check is positive, the cast would be performed automatically, without requiring any additional split action.
Currently
Currently, when we want to cast an object, we are obliged to perform a Split action. This can be interesting when the number of inheritances is limited or known in advance.
The disadvantage is that all cases must be treated exclusively, even the empty one. In many cases encountered with clients, the logic only wants to deal with a particular case and we find ourselves with star logic which quickly becomes illegible (especially if inheritance has been used excessively).
New solution proposed
There are multiple advantages of “FastCasting”:
- Simplification of microflows: reduction of the number of actions, improvement of readability.
- Time saving: acceleration of development.
If we return to the previous example, the microflow will be simplified as follows, making it much more readable and allowing us to not have to maintain split branches when objects inheriting from the same parents are added during development.
When a developer can use a Fast Casting action, he must fill in the following fields of the development interface:
A: only objects available in the microflow and which have been inherited.
B: depending on parameter A, only the predetermined list of possible casts.
C: the name under which the caste object can subsequently be used in the microflow.
These 3 fields are mandatory.The Fast Casting method must return an exception which can be subject to special handling if an event handler has been defined.
To go further…
In my client's current requests, I use an auto-mapping of GraphQL query results to Mendix via a Java method. To do this, I use a json mapping file which serves as a link between a json graphQL structure and the Mendix objects.
There are several strategies for mapping Mendix objects. One of them consists of binding a root object which serves as a starting point for all graphQL query implementations and makes the module dedicated to GraphQL querying independent. However, to be even more dynamic, inheritance is an elegant way. However, we are currently faced with the fact that a Java method will be able to return a generic IMendixObject object but its output casting will become a real nightmare if the client's application uses heritage as a basic concept. The FastCasting option will be so helpful in this case.
Hi Patrick,
I like this idea to improve simplicity as it adds to the existing functionality (while still allowing the inheritance split to be used for different use case types). I do have two remarks that might be of help:
1) When defining inheritance splits, the number of outputscan be limited to a minimum of three: the 'root' entity output, the 'empty' output and a third to cast to a specific subtype. There is no need to extend the split to always contain ALL potential inherited entities. Unlike the 'exclusive split' activity which requires ALL outputs to be modeled when splitting e.g. enumerations.
2) Until the idea is implemented into the platform, it is possible to write a Java action yourself to achieve the same result*. You can use the Type Parameters feature for Java actions to allow specifying the target entity as part of the Call Java Action activity, the Java action itself then only needs one line of code to return the input object, and Mendix will do the conversion for you.
*The only limitation is that you cannot force the Java action to select only entities that are inheriting from the source object. This can lead to casting errors that are not detected until runtime which can be a risk...