Table with Paging

Vaadin 6 / 7 / 8 Framework UI
1

Hi,

Is there any way to add pagination on the table component without add-on ?

Thanks

2

The short answer is, the current Table implementation does not support it. You would need your own code to handle both the back-end (Container) side of paging and the UI controls for switching pages. This might not require client-side code changes, though.

You can see
these
two
 older forum threads where paging has been discussed.

Why do you want to avoid using a add-ons?

3

I’m doing a comparative survey between Vaadin and GXT. I base it on the native components of these two techno.

Thanks for your answer.

4

You should note that a long time ago, the predecessor of Vaadin (old versions of the IT Mill Toolkit) did have a paging table implementation. However, this was dropped when improvements were made to lazy loading of data from the data source, making this unnecessary from the performance point of view.

Normally, a single fully scrollable table is better usability-wise than imposed paging, or worse, the combination of paging and scrolling. The main reasons for paging in the first place were performance in fetching data from various data sources and simplicity when implementing HTML-only interfaces.

5

I disagree with you. Say you have a fixed height table with paging, it is pretty easy to use. but with lazy loading, it’s hard to know which part of the content I am viewing when the data is huge. Say you have 600 records where you show 30 records per view. Lazy loading might load 60 records, so when I scoll a bit, it’s fine. but if i scoll very fast, then the table spend a few seconds to load. and if I scoll backwards, table is loading again. This is not very handy to use IMO

-Xuan

6

It will be the same with paging - when you will start clicking to, say, page “2” and page “10” links, table will load those pages again and again.

As with Vaadin lazy table,when you scroll - table will not load anything until you stop. So user can feel free to drag scrollbar over 10K rows and only when he stops scrolling, table will fetch the current visible frame data.

Please do not forget that table caches some rows above and below visible frame, which can cause mentioned 1-2 seconds delays, especially, when the visible frame is tall. This is tuneable - just set the desired caching parameters to the table, so it will pre-fetch smaller data chunks.

IMO, paging-less table is much more convenient to use, but there is a one small point to keep in mind - if you’re developing web-site looking app, where table height is fixed (to enable lazy loading) and page height is variable, depending on the content, it will look ugly and here is the place where page-style mechanism could fit fine.

7

There are so many flavors of UI preferences here, that is impossible to get right for everyone.

My own preference would be a lazy loading – forward only – table. That is, I might put a limit of say 100 rows to show initially on a query, then if the user scrolls down, I fetch another 100 rows (but keep the original so I now have 200 on the client) so if the user scrolls back up, I’m not running the query again. To avoid annoying your users, the “100” should be part of the query search, so the user can choose first 20, 100, 500 or even “All” based on what they want.

We’ve taken the approach of allowing for a filter query search that then shows all matching records. This is somewhat efficient in that users may want to see all 2000 matches in a scrolling table (best if the table height can be set as a percentage so the bigger their screen/browser window, the more they can see at a glance), or perhaps just listed out “old school” and let them scroll the browser window which most find intuitive compared to scrollbars inside the page.

Many of the lazy loading tables are too inefficient for me, where if I scroll down, the query is run again and only a subset is returned, but when I scroll back up, I have to get them again. For simple DB queries, this may be fine, but many can be quite involved so that running them over and over just so the user can browse through the results can be a pain.

Also, paged table views suffer the inability of using the browser’s “search” feature scan the dataset of various other values.

That said, it would be nice if some more paging tables, perhaps with various options, were part of the Vaadin core. This is not an uncommon need and is provided by “competitor” frameworks like ExtGWT, SmartGWT – and perhaps even GWT soon to come.