XBL: Dynamic bindings by appearance/mediatype/datatype

[ebruchez]

Rationale

UPDATE: Since Orbeon Forms 4.9, the XForms engine supports static bindings by attributes (#1936). This doesn't change the general issue with built-in controls bound by datatype.

Currently, for built-in controls:

• appearances, mediatypes and datatypes are handled in an ad-hoc way
  • custom Java/Scala code in handlers
  • custom JS code on client
  • custom, incomplete switching code on client
• issues
  • complex
  • error-prone
  • inflexible
  • requires compilation of Java/Scala code for even simple changes

    Dynamic binding proposal

• higher-level appearances, mediatypes and datatypes implemented in XBL
• XForms engine changes
  • new CSS bindings
  • appearance/mediatype
    • static case: xf|select1[appearance = "xxf:tree"]
    • DONE with #1936
    • NOTE: xxf:tree and xxf:menu appearances are removed in Orbeon Forms 4.8.
    • P2: dynamic case: allow AVT in appearance/mediatype? what about initial load?
    • defer analysis of tree until initial tree construction
    • then data will be available, which should allow processing of AVT! (as per Alex's idea)
  • datatype

    • 1264 implements this for Form Builder

    • chosen: xf|input:xxf-type(xs:boolean) (here using a dynamic pseudo-class with parameter)
    • rejected: xf|input[xxf|type = "xs:dateTime"] (here using a virtual attribute)
    • rejected: xf|input[class ~= "xforms-type-dateTime"] (here using a class)
  • hook up XBL based on those matches instead of using built-in appearances
  • detect switch of appearance and datatypes
  • Ajax mode: run controls through XBL template and send markup template update to client
• current controls which can benefit
  • date, time, dateTime, boolean datatypes for xf:input
  • rich text editor
  • mediatype="text/html"
  • xf:htmlFragment datatype (#1111)
  • autocomplete input
  • static-readonly mode
  • is appearance mechanism sufficient to control this?
• later
  • even native XForms controls such as plain xf:input can be implemented this way
  • xf:switch/xforms:case optimization where hidden cases are sent to client using same update mechanism as for appearance/datatypes change

[ebruchez]

Had this issue today with a customer: changing the input type to xf:decimal doesn't cause FB/FR to use an fr:number field automatically.

UPDATE: This is now handled in Form Builder with #1264.

[avernet]

+1 from @ahenket to have the xf:input bound to a node of type date be able to automatically use the implementation provided by fr:date.

[ebruchez]

See my new comment on #2800 regarding doing this if there is a bind attribute.

Now this is not as easy as might seem. In XFormsAnnotator, we call metadata.findBindingForElement to identify whether an element is associated with a binding. Here we'd need to find whether xf:input must map to fr:date, and that would use information about the model's xf:bind, which we don't have yet at that time.

So we'd need to move towards making this lazy, as described in #481.