TPac: Paging needed for holds

[Thomas Berezansky]

While it is impressive that TPac can load 3598 holds for a patron on a less than stellar VM I suspect that showing all of them on one page is less than ideal. Especially as it took several minutes to load the page.

Thus I think TPac needs paging for holds, showing maybe up to 50 at once for speed purposes.

Note that while 3598 holds is a tad excessive for real-world purposes, I have run into patrons with over 300 holds (most suspended, but still there).

[Mike Rylander (mrylander)]

Instead of paging, how about a simple cut-off number (say, 100), and if we see that many we assume there are more and display a Show All link at the bottom of the list. That should greatly simplify the code, since paging is more complicated than a switch that enables or disables a LIMIT clause.

[Thomas Berezansky (tsbere)]

I think the LIMIT clause might actually be harder to code in then paging, if implemented in that manner.

Unless I am reading the code wrong, it looks like TPac currently requests an ordered ID List, then fetches holds from that list in batches (looks like of 8 currently). Which means that it already has access to the total number of holds in an ordered fashion.

The ID List appears to return fairly quickly, the fetching details is (I believe) the bottleneck.

Thus while a limit of 100 to start with could likely be implemented fairly quickly and easily (with knowledge of how many holds there are already there), I think paging could be implemented fairly easily as well by setting the batch index to the first hold of the "page" and adding in a max counter.

Having seen what the code already looks like I might take a shot at it myself.

[Thomas Berezansky (tsbere)]

My attempt:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/tpac_holds_paging

[Lebbeous Fogle-Weekley (lebbeous)]

This totally works.

Pushed to master. It's a new feature, so I guess I ought to stop there. Thanks Thomas.