`xf:input` bound to node of type date to use `fr:date` instead of YUI calendar

[ebruchez]

The YUI calendar is not too bad, but we want to move away from YUI entirely at some point. We need to find a good alternative for it.

Step toward #1599.

[ebruchez]

The new fr:date component uses a different calendar. We still have support for the legacy YUI calendar when using xf:input with date type.

[avernet]

Renaming the bug as the issue isn't anymore that we need to find an alternative to the YUI Calendar, but that we want the xf:input bound to a node of type date to use the fr:date, and for this we need to be able to switch the XBL component used for a control after the page has loaded (#1248).

[ebruchez]

In order to do this, we must implement #481 and therefore the "dynamic" part of #1248.

How close are we? We now have a number of cases where we send dynamic markup. That part is not difficult. But the part about the static state is more difficult, since the top-level part (which is the normal case) is cached between XFormsContainingDocument instances. See the discussion in #481 for more. We might want to review that.

[ebruchez]

So this is essentially a duplicate of #481 now. So I am closing this in favor of that.

[ebruchez]

Discussing this with @avernet today. We really, really want to get rid of the old date implementation, which uses the very old YUI date picker.

To fully fix this with backward-compatible behavior we'd need to do what's described in #481, which is fairly involved and not useful for Form Runner at this point.

Form Runner and Form Builder right now do not make use of this. So the only reason not to get rid of this without fixing #481 is one of backward compatibility for users who have written XForms code by hand.

We can decide to do the following:

• remove the old date implementation fully
• document the backward incompatibility
  • dynamic switching of the control implementation by type is not supported anymore
  • if no dynamic switching is required, use fr:date directly
  • if you need dynamic switching or can't update the code to fr:date then you can't upgrade to 2022.1

We could improve on the above by plugging in fr:date automatically if there is a bind attribute that identifies an xf:bind with a date type. But this won't work for ref in the general case, although we could possibly make use of path projection to identify a type in some cases!

Some users write Form Runner-compatible code "by hand", and for them, if they use bind, the could be covered fairly easily.

[ebruchez]

For Form Runner, plugging in fr:date instead of xf:input could be done via bind at runtime form processing. Right now we only do it in Form Runner's annotate-migrate.xsl. This would help users who use Form Runner-compatible code "by hand", but not plain XForms users.

[ebruchez]

RESOLUTION: For 2022.1:

• [x] clarify this bug vs. #481 vs. other bugs!
• [x] remove YUI date support
• [x] upgrade at runtime, for Form Runner, xf:input[@bind] pointing to date to fr:date
• [x] enter follow-up issue(s) as needed
• [x] time no longer autocompletes values like "now"; but date does; see why/how (from the date picker?)

For later releases, we can consider increasing backward compatibility/flexibility.

[ebruchez]

To clarify vs. #481, this current issue is a subset of #481 for fr:date and YUI, with a focus on Form Runner/Form Builder as well, while #481 is about a general mechanism.

[ebruchez]

Checked that for #3657 (in 2018) we already implemented migration of xf:input[@bind] pointing to date to fr:date. Now we need to do this at runtime.

[ebruchez]

Follow-up issues:

• Time values no longer autocomplete #5534
• Date field no longer works #5527
• Can't enter a valid "Date and time" #5389

[ebruchez]

The only thing now for 2022.1 is whether we would like to do another step short of #481 (so without dynamic switching). The only thing that comes to mind is to make a static determination of the type based on bind if present, and maybe using path projection if possible. But is it worth it, that is, is that going to address actual use cases for users who use xf:input bound to a date type?

We do the bind logic already in two places:

• Form Builder: annotate-migrate.xsl
• Form Runner: controls.xsl

But here we are talking about doing this at the XForms level. It's unclear where we can plug that logic of replacing xf:input[@bind] (or even possibly xf:input[@ref]) with fr:date at the XForms level.

Could this be done in ControlAnalysisFactory?

[ebruchez]

Pushing to after 2022.1.