So the Filter API is gone in v8. This means that Data Providers have no typed API for handling data filters. Pretty much all the examples I see use java 8 predicates, which are not solutions for filtering large back-end data sets, and I don’t see any examples that have implemented generic column filtering of JPA entities. My basic use case is a table of 100k+ entities that needs to be shown to the user, sorted and filtered. The paging is handled via the Query api, but you inherently can’t do filtering in memory and paging on the back-end, they break one another.
So my question is - do I basically need to re-write the filtering API or write a completely custom JPA filtering API? I don’t see any other way to enable generic column filtering of a large back-end data set.
I also wonder why the filtering API was thrown out to begin with? It seems it would work perfectly fine within the new Data Provider api.
I’m not really sure if I understood the use case you have there, but in general it should be possible to have something like an JPA Example instance, build based on your filter fields. Together with this example instance you could pass a simple JPA Pageable to your repository findAll(Example, Pageable) method.
The Pageable you pass has to convert the sort information from the data provider to JPA sort information. The page number is always 0. The methos next, previousOrFirst, first will must return always null, hasPrevious always false. Offset and pagesize can be used 1:1 from Vaadins offset and limit given by the Query instance.
Once implemented you can reuse the Pageable for all your projects.
Yea, so in that example you’re having to implement filters from scratch for every single table. That’s what im getting at, filters are a basic feature of most data tables, and it would be a bad practice to implement them over and over whenever nothing is really changing. And the problem with a single field is that it doesnt allow you to easily apply specific filters to specific fields. So my options are…
implement filters individually for every table in my application
re-implement the filter api so that I can turn them on via some API call
It seems the recommended approach is #1. Pherhaps I was spoiled by the old Filter API :). I’ll have to at least attempt #2 first.