TwoOptionsComposite – the downside of PCF composite controls

A while ago, Amey Holden had a wish: a PCF for model driven apps, to help visualize only the ‘flags’ beeing a “yes”. At first I thought that it could be done also with standard possibilities, but she said that there will be quite a few Yes/No fields. Besides that, it should be “colorful and visual”. Here I go: I took the challenge :-).

Maybe is a good idea to consider multi-optionsets before using too many boolean controls. But if you still need quite a few boolean columns, I hope this PCF will help you.

Why a composite control?

Implementing business rules would have been a little crazy, because of so many fields. But there would have been JavaScript for form scripting. That wouldn’t have been hard to implement. But if we show only the controls on “true/yes”, how will the user ever be able to introduce the data for new records? Or for updating the controls that are filtered out because of the value? We need a switch between the “compact mode” (showing only the “true” attributes (columns)) and the “show all” mode. That’s not possible with standard possibilities.

And there is more. If we want something colorful and visual, we need a PCF control. I could have designed a PCF for each boolean control (or yes/no or TwoOptions or whatever this is named lately). But right now there is not recommended to place too many PCF controls on a form. That’s because all the dependencies for a PCF control are loaded for each control again and again, which will bloat the page. That could cause performance issues. And Amey said she has quite a few of those “flags”.

Another problem would be the compact representation of the controls. Having a lot of controls could take a lot of place on a form. A composite control has the chance to show everything at a glance. Using the standard customizations, it’s a little hard to place all controls without wasting too much place. Maybe I missed some important knowledge, but if I customize a section with 4 columns, I don’t get the controls placed as I would have expected. In the images below, you can see what I mean:

PCF Design

OK, so it will be a “Composite Control”. The PCFs are designed to help for that: we are not limited in the number of properties we design for a PCF. All bound properties will interact with the form context just like the first one: we can read and change the values of all of them.

BUT we have to decide in the manifest, how many properties we design. Unfortunately we cannot design a collection of properties. So I had to decide to a maximum number of bound propeties: I took 30 controls. So when we customize the control, we can choose up to 30 controls. I’m not sure if they were all necessary; I can only tell that it’s already enough work to bind all that attributes to the PCF.

Icons

For each of TwoOptions control, there is a supplementary property for definiting the icons. The icons are defined in a text property, in the format “NO_ICON;TRUE_ICON”: icon for false value, icon for the true value, separated by semicolon. The name of the icons can be found in the FluentUI icons gallery. The link between control and the icons parameter is made by the parameter number: Boolean1…Boolean30.

Colors

To define the colors, we can use the standard customizing experience. Similar like for OptionSet controls, for Booleans – TwoOptions – Yes/No controls, we can define for each value a color. For that we still need to use the legacy customizing experience for now:

Behavior properties

Beside the Boolean1, Boolean1Icons, … Boolean30, Boolean30Icons, there are a few properties which defined the overall behavior, shown in the screenshot above in the green area.

We can define the width and and height of a card.

We can choose what controls should be shown, while the others are automatically hidden. To give a little more flexibility, the porperty “Show on” allows us to choose:

• ALWAYS : the controls are shown, no matter what value they have
• TRUE : only the controls with the value “true”/”yes” are shown, while the rest is automatically hidden
• FALSE: only the controls with the value “false/no” are shown. Maybe there are not so many business cases for this setup, but from a logical point of view, I thought it should be included
• NOTNULL: all the controls with the value “true” or “false” will be shown, while the ones beeing empty won’t be shown.

Disabled and hidden attributes (columns)

That’s actualy the main painpoint when making composite controls: we should be able to disable or hide controls at runtime. Unfortunately the PCF sdk provides informations about disabled or hidden state only for the first control. For all the other bound parameters, we get or set only the value, but not the disabled or hidden state.

I had a look on the pcf.gallery , hoping to get inspired by the community. I’ve found there two composite controls:

• Any Composite Fields, by Clément Olivier
• Composite Address Control, by Andrew Butenko

They followed different strategies.

Olivier is parsing the FormXML, to see if the corresponding controls are set to disabled (read only). The problem for me was, that this won’t reflect the disabled or hidden state set using business rules or form scripting.

Andrew is going another way. He designed for each bound attribute, another input property “visible” of type enum, with the values “yes” and “no”. This must be because of the nature of the Composite Address Control: each property has a dedicated reason, so it might not be important to disable or hide included attributes at runtime.

The Andrew’s approach could have been changed to “bound properties”: this would mean that we can set the disabled or hidden by changing the value of the bound attributes using business rules or form scripting. But imagine, for each Boolean I would have added an additional “disabled” and a “hidden” bound property. Remember we have up to 30 controls. The customization has already too many properties; but this would have exploded it. Beside that, just imagine you need to customize that many dummy attributes, only to be able to dissable or hide controls at runtime.

I’ve decided to go with a simplified version of that: I’ve designed two properties:

• Disabled attribute names
• Hidden attribute names

This two properties expect the overall state of all the disabled/hidden controls contained in my composite control.

For instance, if you want to disable the attributes “birdia_boolean1” and “birdia_boolean12” you only need to set the value of this property to “birdia_boolean1;birdia_boolean12” (this are the logical names of the attributes). This can be made by setting this value during the custiming (so at design time), or you can customize a dummy text attribute and bind it to the property. This way you can set the value also using form scipting or business rules.

Of course this solution is not perfect neither. It doesn’t reflect directly the changes made with form scripting or business rules. We need to take care of this separate.

Choosing between a rock and a hard place. But at least I see a door opening, even for runtime changes.

I’ll consider to extend the control for CanvasApps too. Having there the possibiliy to set the disabled or hidden properties using “Power Fx” formulas seems charming. It almost feels like the composite controls were made primary for Canvas Apps.

Compact vs Extended mode

If the “Show on” is not set to “ALWAYS”, when a form is opened, ususally the visible constrols are filtered on the designed value. That’s the “compact mode”.

If we click a card, the value will be changed, but then this card will dissaper, since the value doesn’t correspond to the definition anymore.

To get to see all controls, in order to be able to change their values again, you have a “zoom” button on the right side, which will switch from “compact mode” to “extended mode”.

For instance, if you’ve chosen to see only the “yes”/”true” attributes, by switching to “extended mode” you will see all the controls defined in the customizing, in the definition order. The labels for the attributes being on “false”/”no”/empty will be grayed out. This way you can easily see which cards were hidden in the “compact mode”.

If you would like to try out this composite control, you cand find the solution.zip on my github repository.

I would be happy to hear what you think. I really wonder if there is a better approach!

Here is the result! Compose and enjoy! 🙂

Advertisement