[Grid] Allow config of item selectable provider scope

[stefanuebe]

Describe your motivation

Grid's new ItemSelectableProvider only checks client side selection, but ignores programmatic or already existing selection. While there might be rare cases, where the programmer needs to set a selection, that the user is not allowed to do, it seems to be a more common case, that a selection filter should be applied to client and server side selection. Otherwise the dev needs to implement the "is that a valid selection" check in multilpe places.

There is also the case with the current selection, that is not updated. Might also be something, that could/should be coverable automatically.

Describe the solution you'd like

It would be good, if the setItemSelectableProvider allows configuring in which cases the filter should be applied. This could be done using an enumeration for instance

setItemSelectableProvider(SerializablePredicate<T>); // defaults to client only in the moment, but ALL might make more sense / cover more common use cases
setItemSelectableProvider(SerializablePredicate<T>, ItemSelectableProviderScope);

ItemSelectableProviderScope {
    CLIENT,
    SERVER,
    ALL;
}

Alternative to the enum variant: providing additional information to the callback

setItemSelectableProvider(SerializablePredicate<T>); 
setItemSelectableProvider(SerializableBiFunction<T, boolean>);

The BiPredicate variant not only provides the item, but also the info, if the selection if from the client or server (true/false). Could alternatively be something like a "selection context" or the "selection event" to allow more info in the future.

setItemSelectableProvider(SerializableBiFunction<T, SelectionEvent>);

Describe alternatives you've considered

Implementing the check in a separate method / predicate and pass that to the selectable provider and a server side selection listener (since select in our case can be called from multiple places).

Additional context

No response

[Legioth]

Could you give some example of cases where selection that is applied programmatically should follow the same limits? My gut feeling is that many such cases should anyways also e.g. show a button as disabled in case selection would not be allowed which means that some duplicate logic is needed anyways to control the state of the button.

[stefanuebe]

In our current customer project, the user selection is preserved in the session, so that it can be restored, when the user reloads the page or returns to the page later.

With the current implementation, we would have to check separately, if the last state of user selection still is valid to be applied. Having the selection provider also taking care of the server state, it would work out of the box without any necessary checks.

[stefanuebe]

Another case is, where the selection is set using the applications context menu, providing a "select all" option. That triggers a server side "select all", which then too, has to know, that there is a selection filter, apply that first and then call the grid select. With a server side "auto" filter, that would not be necessary.

In general: having it only applying on client selection needs any grid user (developer, not app user) to know, that there is a selection filter set somewhere, regardless of the source and to always apply that. This means, that implementation details may "bleed" to some places, where it maybe is not allowed / possible / wanted.

[stefanuebe]

A third, common use case is in a multi select grid. I had several projects, where the customer wanted to have the selection being extended or changed, when the row is clicked (anywhere, not just at the selection checkbox). Since this is commonly realized with a server side item click listener doing the selection programmatically, this would also not be using the selection filter.