no reset on dblselect when it depends on other control

[bc]

Using the following fconf

              members: {
                  hoofdgroep: {
                      base: "string",
                      label: "Hoofdgroep",
                      control: {
                          base: "selection-control",
                          options: {
                              uri: baseURL + "/business/wdcit/codetekst/hoofdgroepen",
                              valueTemplate: "{id}",
                              labelTemplate: "{titel}"
                          }
                      }                  
                  },
                  codes: {
                      base: "string",
                      label: "Another colors select (predefined HTML)",
                      control: {
                          base: "dblselect-control",
                          depends: {"hoofdgroep": "/hoofdgroep"},
                          options: {
                              uri: baseURL + "/business/wdcit/codetekst/codes/{hoofdgroep}",
                              valueTemplate: "{id}",
                              labelTemplate: "{langeTekst}"
                          }
                      }
                  }
              }

1. Select the first option in the select, the corresponding items appear in the dblselect.
2. move some items from available to selected
3. change the value of the select-box

the result is that the items in the "available" part are updated correctly but the "selected" part isn't. The previously selected items remain and, when there is no item with the same ID in the new new list, the label is replaced with the id.

[karel]

This is (partly) by design: the control tries to keep the current values.
However, when a previously selected value is not in the new options list,
it should be removed.

[bc]

I suppose it should be possible to configure this? I mean that it should be possible to choose if the selected items remain?

[mpo]

This removal should be handled by the normaliseValue method.

The dbselect should follow the same strategy as the normal select: ie. to remove values no longer in the list of options.

Additionally people wanting to clear the own value whenever the options are refreshed should listen for the update() event. (See ​http://docs.outerthought.org/kauri-docs-current/217-kauri/363-kauri/g2/220-kauri.html#Events )

[jgou]

I think this issue is still open.

[karel]

Replying to mpo:

This removal should be handled by the normaliseValue method.

The dbselect should follow the same strategy as the normal select: ie. to remove values no longer in the list of options.

I don't fully agree. There is an important difference in the UI: For normal selects, you no longer display the removed options that were previously selected (hence you have to unselect them, or the user can't unselect them anymore). For the dblselect control you can still represent removed options.

For the dblselect there are 2 use-cases for having a 'depends' control:
(1) Allow selecting multiple items from one group (e.g. different models from one car make)
(2) Allow selecting multiple items from multiple groups (e.g. different models from different car makes).

If we want to support both cases, then we shouldn't hard-code the removal of selected values, but
let the deeveloper decide (by listening for updates on the options object or by setting an option on the dblselect control)

Additionally people wanting to clear the own value whenever the options are refreshed should listen for the update() event. (See ​http://docs.outerthought.org/kauri-docs-current/217-kauri/363-kauri/g2/220-kauri.html#Events )

[karel]

I just realised that my previous comment contradicts my first comment, so I'll try to rehash my thoughts (and possibly contradict myself once more):

I see three possible behaviours when the 'depends' control changes

• remove all previously selected values (I think this is the behaviour intended in the description of this ticket)
• remove only the values that are no longer a valid option
• don't remove previously selected values.

Given that the third case leads to problems with missing labels I think it's okay if we decide not to support that case.

[karel]

Fixed in r1804. I don't see why that commit didn't automatically close this issue.

[karel]

(In [1804]) Remove values that are no longer in the option list

fixes #384