Building a form with dropdown lists for specialised objects
By: Max Bareis
Tags: Inheritance, How To, Object Oriented, Polymorphism, Mendix

First Approach

I created an incident at support.mendix.com pointing to this article and they suggested:

The possible workaround would be to, instead of using two reference selectors per attribute with conditional visibility to switch between them, this could be implemented with one reference selector per attribute. That reference selector should use the generalization (ObjectB) as its “Data source” and a microflow as its “Selectable objects” to query the correct specialization based on the object type.

The reason why the objects are not showing up is:

[…] it seems that as soon as the type has been switched once, there are two reference selectors (one visible and one invisible) operating on the same attribute at the same time, with conflicting constraints. Whenever one of them tries to set a value, the other one immediately resets it to empty because it’s not valid.

So I changed the snippet (actually I duplicated it and changed the duplicate), but it soon turned out that the label needs to be determined by a microflow too as it is showing (B_Spec_L) even if there is a B_Spec_K Object inside:

Labels can only be dynamically created via calculated attributes, so I added a label attribute to Object B. This is ugly, I know, but by now it looks like the only solution to the problem (despite having multiple fixed forms).

And the label is now showing the attribute

It has to be done on the generalised ObjectB as we do not know the specialisation when asking for the attribute. The microflow behind the attribute only makes an object decision and has the names hardcoded in the end event. Yes, this is really ugly.

And it does not work. The Label shows the correct value only when there is an object selected. When empty there is no association, thus the microflow cannot be called.

Excurs: Why object type decisions are bad

The polymorphism (generalisation-specialisation) pattern opens up a highly flexible and extensible way of grouping objects with the same meta structure. To use the attributes and relations of a meta object, a newly defined child object should only need to define the meta object as his parent (generalisation). With Object type decisions you foil the whole purpose of polymorphism. For example every time you extend your model you have to extend all the object type decisions you have created before. The more specialisations you have the more confusing your microflows will appear.

Back in the days of c-programming the most expensive code fixes were located in nested ifs and switches.

Do! Not! Use! ObjectTypeDecisions!

Outcome

As shown above the object type decisions approach was neither succesful nor commendable. The support team identified the problem. It occurs, because the two selectors operate on the same object. They told me that they will be fully rewriting this widget in React to extend its functionalities and make it coherent with other parts of the platform. It’s very likely that the rewrite will address this, given how conditional visibility is implemented for React widgets.

So I look forward to their solution!