Pfthb

I have a large model to display in a JTable and I need to find a way to paginate the data, in the usual way: display 25 entries, 50, 100, 200, or all, etc. However I need to do this while keeping the ability to sort and filter data, and that should take precedence over the row limit. For example if I have one 1000000 entries from which roughly 50000 begin with each letter, and I want to display the first 100 items then filter only elements that begin with G, I should have the first 100 elements that begin with a G. If I change the filter to B, it should show the first 100 elements that start with a B, which were previously invisible. Also, with no filter, sorting should display the first 100 entries starting with A and sorting again should display the first 100 entries starting with Z.

What I have tried:

1. Limit the value returned by getRowCount to value k in the model. This doesn't work because is sorts/ filter the original k values.


2. I have tried to write a custom filter that only accept first k entries. This doesn't work because the filter is applied once before sorting and I don't know how to reapply it after sorting.


3. Hack my way through the rendered so it doesn't render all cell. Didn't find a way to ask the renderer to do nothing.

Thanks for your help.

Don't mess with the render and table itself - the problem lies elsewhere.

What you need is a table model capable of pagination. You can do pagination in two ways:

• 
  Site-based pagination (Google style): show N entries per page, and show a specific page only (change the current page using buttons: [<] [1] [2] [3] ... [>])


• 
  Infinity scrolling: virtual table model, loading visible data on demand. Clearly the better solution, if you ask me.

Implementing infinity scrolling:

• table model acts as an adapter to a repository, where the actual data is fetched (supporting filtering, pagination (getting the row count and request pages with offset and page size) and sorting).


• table model caches requested pages of data.


• when a specific row is requested (over the table model interface), the table model attempts to serve the row from the cache. If the row is not cached, the table model triggers asynchronous page loading and returns an empty (sentinel) row (the cell renderer can then show a loading indicator for such rows).


• asynchronous page loading loads requested pages from the repository (and makes sure the same page is loaded only once when requesting it multiple times concurrently) and returns them to the table model.


• the table model, once it receives the asynchronously requested page, fires a table model change event for the rows of the received page, so the table gets properly repainted.

Advantages:

• to the user, it looks like all the data is available


• only data which is requested from the model are loaded


• data gets loaded quickly and asynchronously, making the view very responsive


• sorting and filtering is done in the backend/repository, so there's no need to process and discard huge amounts of data in the client


• works well with databases and REST interfaces which support filtering, sorting and pagination.


• that's really the way JTables are intended to be used (model as adapter, flyweight rendering pattern in the UI).