Deactivate livedata pagination when there's only one page

CharpentierLucas · May 28, 2024, 12:13pm

Hello!

Context

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.

MichaelHamann · May 28, 2024, 12:40pm

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.

mleduc · May 28, 2024, 1:11pm

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

CharpentierLucas · May 28, 2024, 2:44pm

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 Thanks!

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

LucD · October 30, 2024, 4:54pm

Hi @CharpentierLucas,

I am interesting in this topic as I generate some liveData in a AWM sheet with this code:

{{liveData
  id="logiciels"
  properties="doc.title,domain,programming_langages,doc.date"
  source="liveTable"
  sourceParameters="className=Logiciels.Code.LogicielsClass&translationPrefix=platform.index."
  filters="domain=$doc.getFullName()"
}}{
  "meta": {
    "propertyDescriptors": [
      {
        "id": "doc.title",
        "filterable": false
      },
      {
        "id": "domain",
        "visible": false,
        "filterable": false
      },
      {
        "id": "programming_langages",
        "filterable": false
      },
      {
        "id": "doc.date",
        "filterable": false
      }
    ]
  }
}{{/liveData}}

Here is an example of a generated table with XWiki 15.10.8 in case of a single entry:

The pagination in this case makes less readable!

The conclusion of this thread is that D should be implemented.
Is it fixed/implemented in a recent release? (I do not see any resolution in the issue XWIKI-21910).

Why to check if a number of 10 and not the limit parameter (set to 15 by default according to the doc)?

Thank you in advance for your help!

Best Regards,
Luc

CharpentierLucas · October 31, 2024, 12:55pm

Hello @LucD !
Thank you for showing your interest in this topic
As you can see on XWIKI-21910: Display pagination of a LiveData only if number of entries exceed 10 by Sereza7 · Pull Request #3030 · xwiki/xwiki-platform · GitHub , I did forget to get back to this issue to propose a proper fix ^^` Our jira should always be up to date, you can subscribe to the jira issue and Github Pull Request if you want to be updated with the progress of this topic.

It was just an idea that was brainstormed at some point. The consensus we reached is that we’d use limit instead of an arbitrary number

Right now it’s not implemented in any release. Unfortunately I can’t give you an “easy” way to apply this patch. If you want it on your distribution, you’ll need to rebuild the livedata webjar on your machine and swap the webjar you have with this new one (while taking care of keeping the version number the same…). If you get the changes I proposed on XWIKI-21910: Display pagination of a LiveData only if number of entries exceed 10 by Sereza7 · Pull Request #3030 · xwiki/xwiki-platform · GitHub right now in your build, it would work like option B. It’s pretty much the process we go through when developing xwiki-platform, it’s quite technical. If you don’t have a strong constraint, I advise you to wait for a release with the patch
Don’t hesitate to remind me about this topic if I still didn’t provide any update on the PR in a week. If you think you can handle implementing a solution, I don’t mind if you take the ticket assignee role either

Thanks again,
Lucas C.

LucD · October 31, 2024, 1:22pm

Hi @CharpentierLucas,

Thank you for your answer!
I am simply trying to improve/promote our XWiki instance (hosted and managed by XWiki SAS) and starting to more understand how to use this powerful tool to which you contribute .
I will wait and remind you if I have no news about this PR.

Best Regards,
Luc

mflorea · November 5, 2024, 10:54am

Besides that, I would add that most live data instances support filtering, and some filters may have initial values (e.g. parsed from the live data state saved in the URL). The fact that a live data instance has a single page or less than X entries at some point doesn’t mean it can’t have more. Toggling the pagination controls when filtering would be very annoying IMO (the live data will jump up and down). We already have the left - right juggling due to the auto resize of the column width, this would make things even worse.

I’m not against having a configuration option in the pagination metadata (from the live data JSON) but I think the case where this would be used (and make sense) are very rare so it’s not worth the effort IMO.

Thanks,
Marius