Allow for selecting number of items per page shown per table

[Liz Blanchard]

Currently, there are some limitations with being able to show the number of pages of items on tables in pagination for Horizon, but I'm thinking it would be a nice addition to add a selection for "Number of items per page"? This way, if users want to browse 100 items at a time, they could select this and it would grab up to 100 items for that page. The limitation of only being able to select "More" to get to the next page might feel a bit less restricting. I'm definitely in agreement it's still not ideal :) Here is a screenshot of what it could look like at the bottom of the table (you can ignore the pagination proposal on the right...):
http://people.redhat.com/~lsurette/OpenStack/Table%20Per%20Page

Note: Users can set this in "User Settings" today for all tables, but the per table setting would be much more targeted.

[Thai Tran (tqtran)]

Hi Liz,

Cindy's work with client-side pagination actually handles this page limit. It's not completely hooked up the API, but its something that is definitely do-able. Currently, she disabled it for consistency sake, but the feature is there! The only point of contention is how we are going to store the user page limits (currently its cookie based, which will get wipe clean if the user clears cookie or doesn't have it enabled, alternative approach would be to use localstorage, which is supported by all major browsers).

http://tablesorter.com/docs/example-pager.html
https://review.openstack.org/#/c/84531/

[Raghuram Gundimeda (raghuram-gundimeda)]

As I was commenting in bug #1359238, pagination is not necessarily an answer for data tables, always. While it might add to the overhead of code and its maintenance, it definitely adds (avoidable) intellectual and motor load on the user (deciding, customizing, traversing back / forth in trying to reach his target row, accompanying errors while doing so, etc).

I am not aware of all table traversal features that we currently have in Horizon, but we can definitely go for something that saves on issues I just stated - say, as a fixed header table with scrollable but fixed height, that lazy-loads data (fetch rows on demand) as the user scrolls down. We can do away with pagination and customization + their overheads altogether.

Just some thoughts...

Thanks!

[Gary W. Smith (gary-w-smith)]

This would be unnecessarily confusing for the user

[Ying Zuo (yingzuo)]

A pagination setting per table is overkill.

[David Lyle (david-lyle)]

This introduces overhead in the session and potential confusion for the user.