Support binding appearance and another attribute

[ebruchez]

From #2394:

 xf:select1[appearance ~= full][selection = open]

[ebruchez]

This issue would cover other cases, like:

xf|input[appearance ~= character-counter][fr|pdf-template = true]

Note that #4370 calls for cumulative appearances support.

[ebruchez]

• implement XBL engine support
• check that Control Settings: incorrect description/appearances with some form controls #6811 hasn't regressed
• unit tests

[ebruchez]

See also #6811.

[ebruchez]

For Form Builder, trying to figure out the logic of appearances again.

From the "Control Settings" dialog, we call:

• possibleAppearancesByControlNameAsXML()
• findVirtualNameAndAppearance()

How is this impacted, if at all, by adding support for binding to appearance + other attribute?

At form compilation time, an element and its attributes, as well as the index of bindings, results in the selection of zero or one binding. This doesn't use the datatype, which is unknown.

At Form Builder design time, we have the notion of "virtual name", which is the name associated with an element name in a CSS selector on the same binding, but taking the datatype into account.

To compute the virtual name, we call findVirtualNameAndAppearance(), passing the control's original :

• element name
• datatype
• appearances (as tokens)

It seems that we should then pass, also, the other attributes. Right now, we don't. This should, in fact, work exactly as at compilation time, to identify the original binding, with the possible exception that at design-time, we only support matching appearances with AttributePredicate.Equal or AttributePredicate.Token, while at compilation time we have more flexibility (which should not be used right now by Form Builder controls).

• handle other attributes in findVirtualNameAndAppearance()

[ebruchez]

In findVirtualNameAndAppearance(), we have this comment:

only a direct binding can be an alias for another related binding

Trying to figure out what it means!

findVirtualNameAndAppearance() is called in Form Builder's Control Settings from:

• newElementName(), from renameControlIfNeeded(), from writeAlertsAndValidationsAsXML()
• findNewControlBinding()

We take the information from the form definition:

• element name
• datatype
• appearance/attributes

Then we call findMostSpecificBindingDescriptor(). If that includes an appearance, we stop.

Examples:

• fr|date, xf|input:xxf-type('xs:date')
• fr|fields-date, xf|input:xxf-type('xs:date')[appearance ~= fields]
• etc.

In the form definition, we therefore must have the direct binding. In theory we could also support:

• fr|fields-date, fr|date[appearance ~= fields], xf|input:xxf-type('xs:date')[appearance ~= fields]

but we don't. So the assumption is that the "most specific binding" is a direct binding, and if it isn't then we fallback.

Now, how is this impacted by the addition of support for other attributes? Right now we have:

• fr|open-select1[appearance ~= full], fr|open-select1, xf:select1[selection = open]
• fr|open-select1[appearance ~= minimal]

This lets Form Builder:

• use fr:open-select as an element
• vary the appearance between full and minimal

Now let's say we add:

• xf:select1[selection = open], xf:select1[selection = open][appearance = full]
• xf:select1[selection = open][appearance = minimal]

The "most specific binding" will be:

• fr|open-select1[appearance ~= full]: fr|open-select1[appearance ~= full] (rejected)
• fr|open-select1: fr|open-select1` (used)
• xf:select1[selection = open][appearance = full]: xf:select1[selection = open][appearance = full] (rejected)
• xf:select1[selection = open]: xf:select1[selection = open] (TBD)

Note that there are no datatypes involved here.

I conclude that right now, the code is not ready to handle the migration from, say:

• from fr|open-select1
• to xf:select1[selection = open]

I'd suggest first, for Form Builder:

• to make things work again
• then to tackle changes for Support binding fr:open-select1 with selection="open" #2523

[ebruchez]

Trying to refine the logic of appearance selection.

• before, we didn't handle extra attributes: we checked
  • virtual name
  • optional datatype
  • and varied the appearanves
• now, we'd like to

Say we have the bindings:

• a[appearance = foo]
• a[appearance = bar][a1 = v1]
• a[appearance = baz][a2 = v2]

Then:

• <a>
  • should support no appearance and foo
• <a a1="v1">
  • should support no appearance and bar, but not foo
• <a a1="v1" a2="v2">
  • supported? use cases?
  • if so, should support no appearance, bar, and baz, but not foo?

[ebruchez]

Excel export used to output:

<control name="currency" datatype="decimal" control-type="fr:currency">

Now outputs:

<control name="currency" datatype="decimal" control-type="xf:input" control-appearance="xxf:currency">

We do have that xf|input[appearance = 'xxf:currency']:xxf-type('xs:decimal') binding for fr:currency. It is a little funny that we use this as an appearance, but the new output seems correct, as we call findVirtualNameAndAppearance(), which calls findMostSpecificBindingDescriptor().

Interestingly, that change causes an appearance selector to show in Control Settings, while it didn't before: