Closed jhult closed 4 years ago
I think the above exception is okay. I inadvertently caused this by switching away from a DataLoader
and using setItems
(with my List
) directly on a Grid
. I did this because of the real issue: Grid
no longer implements HasDataProvider
. I believe fix is to update eu.vaadinonkotlin.vaadin10.vokdb.DataProviders
similar to the following:
import com.github.mvysny.vokdataloader.DataLoader
import com.github.vokorm.KEntity
import com.vaadin.flow.data.provider.DataView
import com.vaadin.flow.data.provider.HasDataView
import eu.vaadinonkotlin.vaadin10.DataLoaderAdapter
import eu.vaadinonkotlin.vaadin10.VokDataProvider
/**
* Sets given [dataLoader] to this [Grid], by the means of wrapping the [dataLoader] via [DataLoaderAdapter] and setting it
* as a (configurable) [com.vaadin.flow.component.grid.Grid.Grid.getDataProvider].
*/
fun <T: KEntity<*>, V: DataView<T>> HasDataView<T, V>.setDataLoader(dataLoader: DataLoader<T>) {
setItems(dataLoader.asDataProvider())
}
/**
* Returns a [VokDataProvider] which loads data from this [DataLoader].
*/
fun <T: KEntity<*>> DataLoader<T>.asDataProvider(): VokDataProvider<T> = DataLoaderAdapter(this) { it.id!! }
eu.vaadinonkotlin.vaadin10.DataLoaderAdapter.DataLoaderAdapter
needs some updates as well:
import com.vaadin.flow.data.provider.HasDataView
/**
* Sets given [dataLoader] to this [Grid], by the means of wrapping the [dataLoader] via [DataLoaderAdapter] and setting it
* as a (configurable) [Grid.getDataProvider].
* @param idResolver provides unique ID for every item. The ID is then used to differentiate items.
* See [com.vaadin.flow.data.provider.DataProvider.getId] for more details. Typically every item
* has a primary key of type [Long], but any Java/Kotlin object with properly written [Any.equals] and [Any.hashCode] can act as the ID,
* including the item itself.
*/
fun <T: Any, V: DataView<T>> HasDataView<T, V>.setDataLoader(dataLoader: DataLoader<T>, idResolver: (T)->Any) {
setItems(dataLoader.asDataProvider(idResolver))
}
Sounds good, thanks! I'm currently on a vacation but I'll take a look next month :+1:
Thank you for letting me know :+1: It feels a bit weird that Grid would simply stop implementing HasDataProvider since that's a backward-incompatible change. However, if that's the case, then we need to figure out how to add extension methods both to HasDataProvider and to HasDataView while keeping some kind of compatibility with Vaadin 14...
@jhult Which Vaadin version are you testing with please?
I'm using a snapshot of Vaadin 17 with Flow 4.
Relevant discussion can be found here.
You're right, in Vaadin 17 the Grid will no longer implement HasDataProvider
. One solution would be to compile against Vaadin 17 and add the code as you suggest, however Vaadin Gradle Plugin unfortunately doesn't support Vaadin 17 and so the example project would stop working...
Alternatively, since Grid will not lose the setDataProvider()
function, we could introduce an overload specifically for Grid:
fun <T: KEntity<*>> Grid<T>.setDataLoader(dataLoader: DataLoader<T>) {
setItems(dataLoader.asDataProvider())
}
That way VoK can still be compiled with Vaadin 14 but would still work with Vaadin 17. This could be a temporary solution until next Vaadin LTS is released, then we can completely move to HasDataView and drop the HasDataProvider interface.
I need to check though whether the autocompletion will not be too confusing (offering two setDataLoader() functions for Grid).
The binary compatibility is now out of the question because of https://github.com/vaadin/flow/issues/8831 . Now we have two options:
HasDataProvider.setDataLoader()
extension methods will still active properly under Vaadin 14.I'd like to avoid 1 if possible, because it introduces a constant need for merging stuff between the two branches. I had to go with 1. with Karibu-Testing and it's a bit annoying.
I agree option 1 sounds like a pain and should be avoided if possible. Let me know if I can help in any way.
Perhaps the best way could be having an additional module for Vaadin 17+... I'll think about this option.
The new functionality is now present in new module vok-framework-v17-vokdb
.
There are updates needed to support the new DataProvider improvements that are being done in Vaadin #8054.
Example: