The display type of BT-106 in subtype 18 is incorrect.

[GarrusMD]

In subtype 18, BT-106 is defined as TEXTBOX:
{
"id" : "BT-106-Procedure",
"contentType" : "field",
"displayType" : "TEXTBOX",
"description" : "Procedure Accelerated",
"_label" : "field|name|BT-106-Procedure"
}

In subtype 16, BT-106 is correctly defined as COMBOBOX:

{
"id" : "BT-106-Procedure",
"contentType" : "field",
"displayType" : "COMBOBOX",
"description" : "Procedure Accelerated",
"_label" : "field|name|BT-106-Procedure"
}

Apart from this concise case? What is the added value of the ‘displaytype’ field? Shouldn't the field data "type" from fields.json be sufficient?

[YvesJo]

Hi,
Thanks for reporting that concern.
Be aware that this has already been reported (cf. #1078) and shall be fixed with SDK 1.14.
KR

[GarrusMD]

Thank you. Can you explain to me why the displayType is needed at all?

Can't all the necessary information be derived from the fields.json attribute "type"?

[YvesJo]

My colleague in charge of the UI is unfortunately currently not there, so I will try to reply to the best of my knowledge.
displayType could most likely be deduced from the attribute type, however this would restrict the available display options.
Radio buttons, check boxes or dropdown lists are various possible options I see for fields of type code (of course depending on additional properties like repeatability).
I'm not aware of all the current limitations, however, I guess room should still be left for later evolutions.

[GarrusMD]

Is there an example where the display type would be restricted? If not, please dismantle this double structure. That only leads to problems.

Please note, that the error mentioned above means that several German platforms are currently unable to use subtype 18 forms at all.

[YvesJo]

As illustrated previously, for some field types, it could be possible to go for an option or another, this is a design and technological choice. Enforcing the display type based on the field type does not allow you to have that variation for a given type.
The current concern is already present in SDK 1.9 and has not been reported until recently.
In the local implementation, nothing prevents the use of the field type to select the expected displayType. Also provided NTDs may be updated to satisfy the local implementation and this could be a workaround until this issue gets official fixed.

[GarrusMD]

I would kindly ask you to give me a specific case. The SDK is full of places where a theoretical case (which may only occur in the future) leads to unnecessary complications from our point of view.

We (the german procurement data service) know that we can use the field type and do so because there have been several such faulty display types in the past. Nevertheless, several other German platforms are affected by the current case. We assume that these platforms have updated directly from SDK 1.7 to SDK 1.12.

[GarrusMD]

Of course, we also know that we can build a national workaround. After all, this is one of our main activities because the EU SDK is the way it is.