Variable of type Object - Mendix Forum

Variable of type Object

10

Hi !

Today variables can’t refer to Object, and it would be very useful.

For example in a microflow with following algorithm :

  1. try to retrieve an Object → named “ExistingX”.
  2. if “ExistingX” is empty, create a new object named “NewX”
  3. then, whatever we want to do, it has to be duplicated both for “X” and “NewX” (it’s not possible to merge the flow into a single one)

If it was possible to define a variable of type Object, then it would be possible to do :

  1. Create an undefined variable of type Object named “X” 
  2. Try to retrive “ExistingX”
  3. If ExistingX is not empty, update the value of “X” with “ExistingX”
  4. Else, create “NewX”, and update “X” with “NewX”
  5. Then, merge the flows into 1, and use “X” onwards
asked
4 answers

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.

Created

There are more complex scenario’s where this would be a great addition!

Created

Hi Erik,
Yeah, that’s what I currently do

Created

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.

Created