You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 6, 2021. It is now read-only.
E.g. let's say I have a table showing some entities and I want to select the one that has a specific ID.
For in-memory data providers, that's trivial.
I'm not quite sure what the best practice is for data providers with callback, though, [as I'm] a bit unsure about how to handle wanting to select an item that vaadin may not yet have fetched from the backend.
in order to differentiate between beans, the standard Java machinery of equals() / hashCode() is used, on the IDs returned from items by the DataProvider.getId()
So, if you have a bean, say Person, and you know that equals()/hashCode() only takes advantage of the ID field within that bean, you can in theory select a particular person by creating a new Person, setting the ID and passing it to the select() method.
However, this is quite fragile since it depends on the fact that equals/hashcode implementation never changes.
the best and most resilient method is to fetch the actual bean from the back-end by its ID, then pass that to the select() method.
Related, but not mentioned in the conversation with the support chat yet:
Do I need to consider anything special when selecting multiple items in a grid powered by a data provider with callbacks where the selected items may be spread across multiple backend queries?
The text was updated successfully, but these errors were encountered:
Thank you :) I was on the other side of the Expert Chat ;) I'd add the following info:
The documentation doesn't mention in any way whether it's possible to select a row in a Grid based on the entity ID.
It's not clear whether providing some custom bean-to-id mapping via the idGetter parameter of CallbackDataProvider would solve this.
I think most probably not. For example say you have a Person with a Long ID, having equals/hashCode only take advantage of the Long ID.
The recommended way is to fetch a full-blown Person from the backend by the ID, then select that bean. That way, you can obtain a full-blown Person from the selection set. However, that requires a backend fetching.
One workaround would be to create a new Person and only file in an ID, then select that object. That should work, however the getSelection() now returns this kind of dummy Person object. Also, this solution depends on a concrete implementation of hashCode/equals and will break subtly when the implementation is changed.
If the idGetter would return the ID out of Person, and would also accept Long and return an identity, then it would be possible to have a Grid<Object> and select according to Long; however this will basically erase any type safety and will get ridiculous quickly.
In short, we're looking for a guidance on what to do next - is it an omission in docs, or an omission in Grid's API?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
From a conversation with your support chat:
Related, but not mentioned in the conversation with the support chat yet:
Do I need to consider anything special when selecting multiple items in a grid powered by a data provider with callbacks where the selected items may be spread across multiple backend queries?
The text was updated successfully, but these errors were encountered: