Deactivate livedata pagination when there's only one page

Hello!

Context

Jira ticket · Github PR

On some of the native Live Data tables included in XWiki, displaying the pagination element is unecessary because we do not expect any more element to be created, and there’s only one page.

Proposal

We found out a few ideas when thinking about how to solve it:
A. (initial ticket info filled up by @surli ) Disable the Live Data pagination when there’s less than 10 items in a table.
B. (my take on the issue, proposed in the PR) Disable the Live Data pagination when there’s only one page.
C. (@mleduc 's idea / preference) Keep Live Data pagination except when the corresponding admin parameter is turned ON (default OFF). Then same as B.
D. (additional idea I had) Same as C, but with a macro parameter instead of an admin preference, by default the pagination is always ON.

Explanation

  • In my opinion A. is not stable enough, and relying on an empirical value can become a burden for users understanding: So I add one item in my table and all of a sudden the pagination shows up.
  • An advantage of A and B would be that this behaviour would be shared by all the updated wikis. It doesn’t need extra consideration from the Admin when setting up a new wiki, and they allow for the best consistency of the feature.
  • An advantage of C and D would be that there is no change to the way a Live Data is displayed.
  • An advantage of D would be that we can adopt different policies for different tables, giving the most fine grained control to the user over this new feature.
  • An issue of D would be that it makes using the Live Data macro a bit more difficult.

Conclusion

In my opinion D > B > C > A.
What solution do you prefer? Would you rather keep things as is and close the Jira issue as a Won't fix? Did you think of additional advantages and drawbacks for each solution?

Thank you!
Lucas C.

Could you please explain what the need is this for this feature? What do we expect to gain from this feature?

Also, please keep in mind that attachments currently use Live Data with a page size of five. Would this mean that if there are between five and ten attachments on a page, you’ll only be able to see the first five attachments if option A is implemented? This seems bad. Further, does option B mean that when I select a page size large enough to show all entries, the selection will magically disappear, and I won’t be able to change it back to a smaller page size?

Overall, this seems like a feature that would really only make sense if the Live Data has a data source that won’t ever provide more items. I would be okay with D if this is implemented as a customization option in the pagination metadata (i.e., not a macro parameter but a property inside the “pagination” metadata where we already have various options to customize the pagination display).

So from my side +1 for the proposed variant of D, -1 for A, B and C.

Actually my initial though was more along option D (i.e., a macro instance configuration, and not a global one).
And I agree that this option is expected to only be used in cases where the pagination is supposed to be a single page 99% of the time (i.e., except for odd cases).

So I’m also +1 for option D and -1 for A, B, and C.

Thanks

We want to simplify the UI in some places. The live data is quite heavy on UI, and in some cases it’s not necessary to get the whole thing.

I was thinking to only evaluate the state when first loading the table. If the page size changes, the state of the pagination stays the same.

I didn’t really look into the livedata parameters yet, I’ll be sure to set it as a pagination metadata :+1: Thanks!


Then I’ll go along with D. :slight_smile:
Thanks for your feedback!