XForms: date, time, dateTime, and boolean inputs in XBL

[ebruchez]

This would solve a number of issues. For example, we would like to use a control layout compatible with Bootstrap to help with CSS styling. We can hardcode, but that's not so nice, and then the JavaScript client must be modified to recreate the inputs. That's changes in two places.

Two implement this, we need:

• [x] implement #437 "Support XBL "value" mode" (needed so that control dispatches value changes)
• [x] support XBL binding for xf:* elements (right now, only elements not in the XForms ns are supported)
• [x] determine directory format for automatic includes to support matching on appearance, xforms|type pseudo-class, and/or plain classes (right now format only supports matching on element QName)
• [x] update XBL matcher to support those formats too
• [x] see how Noscript mode is impacted
• [x] create XBL components for the date, time, etc. types
• [ ] static state: cannot share shadow tree for dynamic bindings (those which depend on xforms|type)
• [ ] remove specific Java/JS code which handles those formats

We already support updating a shadow tree dynamically within xxf:dynamic. This was implemented to update fr:section in Form Builder.

See also #1248.

[ebruchez]

How things work now:

• ConcreteBinding has ref to AbstractBinding (this is still ok)
• ComponentControl has ref to ConcreteBinding, retrieved from partAnalysis.xblBindings
• ComponentControl is able to update the binding, BUT this is prevented at the top-level, because:
• the part also contains the Scope and indexes objects

Since the top-level part is shareable, something has to change, and this is probably the hardest part (caching!).

One possible approach:

• use new PartAnalysisImpl for each top-level component with dynamic binding
• non-top-level components with dynamic binding do not require a new part!
• top-level components with dynamic binding must not have an initial binding (?)
• OR they could, and that could be shared between parts if they don't change (case of most forms)
• issue: if a sub-part is removed, then there is a risk that some stale top-level information willl be found
• so the best way might be to prevent sharing completely for dynamic top-level components

[ebruchez]

Based on the above, the difficulty seems now to be how to handle the static state for those XBL controls which depend on the datatype.

Since the above was written, ComponentControl has a hasLazyBinding option, which currently only works for nested parts (i.e. Form Builder) which are specifically annotated. See #3477.

How hard would it be to change this condition to add this?

|| (part.isTopLevel && hasTypeBinding)

In addition, AbstractBinding is still not lazy, and it should be. Further, it shouldn't be stored in the part, as discussed above, since the part is shared.

In short, not only ConcreteBinding but also AbstractBinding cannot be determined during static analysis, and they cannot be stored directly into ComponentControl. We still need an indirection there.

[ebruchez]

Reviewing the above, that makes sense. Right now we associate an AbstractBinding directly in XFormsAnnotator as an IndexableBinding. When we build the component tree, we create a ComponentControl based on that.

The indirection we need here is something that says "here is an element whose actual binding may depend on a type that we don't yet know". For example xf:input might have it's plain, string implementation (which would also need to be done in XBL, which would be fine probably), or its fr:date, fr:number, etc. implementation.

So instead of storing a IndexableBinding, maybe an ADT with EagerIndexableBinding | LazyIndexableBinding.

At some point, either statically (case of bind which is known before static analysis is complete) or dynamically (case where things are more dynamic), we can resolve the binding to a concrete AbstractBinding. As a first step, we could only address the static approach. This is easier as it means that at the end of the static analysis, we have a resolved binding and that can stay in the shared PartAnalysis.

As a second step, we can do the dynamic part.