webadmin: Fix reseting of graphics

[ljelinkova]

When the BIOS type changed, the graphics list was always reset even though the video type stayed the same.

This was because the setting of the items and selected item was separated in https://gerrit.ovirt.org/c/ovirt-engine/+/118132

This patch goes back to setting the items and selected item at once but making sure that the selection model is not
used to avoid issues fixed by https://gerrit.ovirt.org/c/ovirt-engine/+/118132

Bug-Url: https://bugzilla.redhat.com/2078193

[ljelinkova]

/ost

[rszwajko]

Looking at https://gerrit.ovirt.org/c/ovirt-engine/+/118132 it seems that the main problem was that:

ListModel:setItems(Collection value, T selectedItem) [...] uses OvirtSelectionModel, but is not synchronized with method setSelectedItem()

However looking at ListModel constructor (link below) this should work - the handler should synchronize value from OvirtSelectionModel to ListModel.

Regarding the new flag useSelectionModel - it explicitly de-synchronizes between OvirtSelectionModel and ListModel which breaks the contract. Perhaps we should use/create a different model instead?

ovirt-engine/frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/ListModel.java

Line 155 in f9a19e2

this.selectionModel.addSelectionChangeHandler(e -> synchronizeSelection());

[ljelinkova]

Yes, the value is synchronized from the selection model to the selected item(s) but the problem is the other way around - when you set item(s) using setSelectedItem(s)(), it is not propagated to the selection mode. And if you mix those two together (setSelectedItem() with setItems(items, selectedItem)), the selected item is overridden by selection model.

This could be fixed but given that this is the key model used across the whole webadmin, it could break many other dialogs.

[rszwajko]

@ljelinkova

if you mix those two together (setSelectedItem() with setItems(items, selectedItem)), the selected item is overridden by selection model.

This could be fixed but given that this is the key model used across the whole webadmin, it could break many other dialogs.

OK. Fixing this problem is risky indeed. I would rather leave the responsibility for correct handling such cases close to the usage: either the code uses selection model or not. If it does use it then it should make sure that setSelectedItem() is not called. Otherwise the selection model should be disabled to avoid synchronization issues.

In case of displayType, it seems that we are not using selection model functionality so lets disable it entirely in that one place i.e. by creating and using a constructor

public ListModel(boolean useSelectionModel) {
   // ...
  if (useSelectionModel) {
      this.selectionModel = new OvirtSelectionModel<>(isSingleSelectionOnly());
      // ...
  } else {
      this.selectionModel = new DummySelectionModel();
  }

What do you think?

[ljelinkova]

I like the idea to explicitly mark "do not use the selection model" in the constructor. I'll update the PR.

[rszwajko]

GWT library code seems to perform null-checks before accessing selection models but this is not consistent.
However GWT uses also another way - NoSelectionModel that could be more useful in our case. This mode was missing in our higher order model. Please check PR #357 for details.

[ahadas]

minor comment, other than that - lgtm