What is the expected behavior when a selected select value is temporarily removed?

[eyelidlessness]

Breaking out an issue to track this discussion thread on #14.

Current (albeit incomplete) behavior

The intent of the behavior in #14 (which is incomplete, as called out in the comment) is this:

Given a form like:

<instance>
  <data>
    <sel />
    <fil />
  </data>
</instance>
<instance id="sel-opts">
  <root>
    <opt><val>option a</val></opt>
    <opt><val>option b</val></opt>
  </root>
</instance>
<!-- ... -->
<select ref="/data/sel">
  <itemset nodeset="instance('sel-opts')/root/opt[contains(val, /data/fil)]">
    <value ref="val" />
  </itemset>
</select>
<input ref="/data/fil" />

If a user...

1. Answers /data/sel, selecting "option a"
2. Answers /data/fil, entering "b" (causing "option a" to be removed from /data/sel's available items)

Then the form state is updated so that the prior selection of "option a" is:

• Cleared from /data/sel
• Retained in memory until¹ another selection is performed with the filtered options for /data/sel

At this point, the form's instance state is correct, but it allows either:

Next (A), if a user...

3. Answers /data/sel again, selecting "option b"

   Then the form state is updated so that:

   • /data/sel is set to "option b"
   • The previous selection of "option a" will¹ no longer be retained

4. Clears /data/fil (restoring "option a" as an available option for /data/sel)

   Then the form state for /data/sel is unchanged from step 3

... OR ...

Next (B), if a user...

3. Clears /data/fil (restoring "option a" as an available option for /data/sel) without any further user action on /data/sel following step 1's affirmative selection of "option a"

   Then the form state is restored to its state after step 1 (i.e. the value of /data/sel is again set to "option a")

Alternative behavior

Per the discussion thread, the alternative would be not to retain any memory that "option a" had been chosen (step 1), once that option is filtered out (step 2). Also per the discussion thread, this is the behavior in JavaRosa. Furthermore, it would be fair to say it is the obvious default behavior. It is unquestionably the behavior we'd implement if we skip asking the question posed by this issue.

Footnotes

1. This aspect is currently unhandled, but will be handled the same way regardless of the broader answer to the question posed by this issue. ↩ ↩²