A12 Puzzler: Two fields should trigger two dependent controles

Tool Set UI Designer
1

Requirement

There are two trigger fields:

  • Trigger 1 (YES or NO)
  • Trigger 2 (YES or NO)

and two dependent groups

  • Group A
  • Group Z

If (Trigger 1 == YES)
Group A should be displayed

If (Trigger 1 == NO and Trigger 2 == YES)
Group A should be displayed

If (Trigger 1 == NO and Trigger 2 == NO)
Group Z should be displayed

This example models don’t work:
A12 21.3.6
A12Puzzler.xml
data.xml

Puzzler
What’s the A12 way to build this?

I’ve found a solution but it is very complex and difficult to understand. I’m looking for the best easy solution.

My Solution
I hate this solution
A12Puzzler_Solution.xml

I’m very sure nobody can understand what’s happening when they have to maintane this model.

2

may be @henner-grey-void can help you?

3

You can do that by using computations on 2 auxiliary fields receiving different values depending on the conditions.
Unfortunatly these fields have to be part of the UI model (in order to serve as trigger) but you can set them invisiable by “dependent field”.

4

Hi Tobias,

thank you for the puzzle. That is a very refreshing way of starting a discussion.

My solution includes kind of a workaround and I have to admit that I used the current versions of the Data Modeler (v.23.1.0) and the UI Designer (v23.2.0).

Data Modeler:

  • Create a third trigger field
  • Fill Trigger 3 via computation based on the input from Trigger 1 and Trigger 2
    UI Designer:
  • Use Trigger 3 to display/hide your Groups A/Z
  • Hide Trigger 3 dependent on Trigger 1 or Trigger 2 (optional)

Data Model:
DomainTriggerTest.xml (2.6 KB)
UI Model
TriggerTest.xml (4.2 KB)

This workaround is easily extendable by more complex preconditions or a higher number of display cases.

Cheers

5

Right. Unfortunately in 21.6.3 computations can only fill Number fields which cannot trigger dependent controles.
And this solution is also not very “clean” or “minimal”.

The ideal solution would be wo not have computated fields as the trigger but the condition of the computation. So we would not need additional fields in the data model or the UI model.

6

In version 21.6.3 a computation can only fill a number field. So this solution doesn’t work for me right now, but I like it quite a bit.

7

at 1)

  • solved in 23.1
  • meanwhile you can use custom computation instead - using annotations for any type

at “ideal solution”:

  • although I am not in charge I am pretty sure that using complex conditions as triggers is beyond the scope of the ui model
  • and indeed computations are designed exactly for such cases (among other aims)
  • triggering by fields of any type is indeed an issue which has been already been requested: <INTERNAL_LINK>
8

Please note that with versions 23.2.0 of the Data Modeler (23.3.0 Kernel version) you can also use the transient flag on computed fields.
This will avoid making these technical fields show up in the serialized documents (XML or JSON).
I.e. the data that is transferred between client and server would already be stripped of those fields that exist purely for technical reasons.