Today variables can’t refer to Object, and it would be very useful.
For example in a microflow with following algorithm :
If it was possible to define a variable of type Object, then it would be possible to do :
I agree that this would be very useful. The workaround is clunky and doesn’t really work for all situations. For example, looping over a list and updating object references as I go along, especially if I don’t know ahead of time how many times I might need to update.
In my particular example, I’m creating a tree of objects based on values in a list. Not every item in the list generates a node in the tree, and we don’t know ahead of time how many nodes we’ll be creating. It would be very helpful if we could just have a reference to a “currentNode” object, update its parent, then set “currentNode” to be the parent object for the next iteration.
We can hack a workaround with a recursive algorithm, but for various other reasons it really is not the best or most intuitive solution here. Being able to reassign object references is a very common feature of most programming languages, and it’s very frustrating not to have it.
There are more complex scenario’s where this would be a great addition!
Yeah, that’s what I currently do
What you’re describing here is actually one of the most common patterns you’ll find in Mendix applications: the GetCreate.
Using this microflow as a sub, will leave the calling microflow unconcerned how the object was instantiated. In the use case you describe, this folds all your requirements into one, bar the update. You’ll most likely want to follow this subflow with a change on the object in another subflow.
By the way, this gets even more flexible with inheritance and return values.