Pagination needed

[glenl]

There are several instances where a user can get a substantial amount of output:

• If they click on 'List all Pieces'
• If they click on the submit button of the advanced search without filling out any search criteria

The problem is twofold:

• It is a lot of data, especially on a small device which may be on a cellular network
• The piece info uses relatively large tables that require lots of scrolling on a small device

The difficulty to a solution will be that we employ a filtered linear search.

• To know we have 100 results we have to do a complete search with the filters applied.
• To display the first 25 is simple enough with a counter.
• To display the last 25 requires that we search through the first 75.

The functionality we need is similar to a database query using offset and limit. Can this be done relatively efficiently with our current search mechanism?

[ksnortum]

I have been looking into this. It is possible, but difficult because the data comes from multi-line records in a text file. When displaying the next page, we would have to essentially go through the same logic that builds the page, but not create HTML output until we get to the page we want. I am afraid that this might make already difficult code very hard to follow.

[ksnortum]

I have simple pagination done. I can create a pull request if you want to see it and then we can expand on it. Or should I keep working on it?

The simple (non-advanced) search works, paging forward only. Page size is in HTMLCommon. I don't have a "page back" link yet, and advanced search will not work.

[glenl]

If I understand what you are doing, we do almost the same search each time we serve a page but stop when we reach the page size? It is difficult with this file format to take the load off the server but at least we don't throw down 1900+ pieces of info. It might be a good idea to review this before getting too far along.

[PaulMorris]

David Kastrup on the mutopia mailing list:
"The "Next 10" lists does not mention how many entries there are actually (like when looking at the list of "Traditionals"). Nor is it possible to go back, or forth other then to the next 10."

Perhaps we should hold off on pagination until we can do a fully featured implementation? Or we could show, say, 100 per page instead of 10, which would reduce the impact of the issues David raises.

(More concise search result listings will also help with the user experience for large results -- less scrolling.)

[ksnortum]

Changing 10 to 100 is a one-line change. Going back and forth, and estimating the number of hits, will be easier when we have a database.

Knute Snortum (via Gmail)

On Wed, Feb 17, 2016 at 10:26 AM, PaulMorris notifications@github.com wrote:

David Kastrup on the mutopia mailing list:

"The "Next 10" lists does not mention how many entries there are actually (like when looking at the list of "Traditionals"). Nor is it possible to go back, or forth other then to the next 10."

Perhaps we should hold off on pagination until we can do a fully featured implementation? Or we could show, say, 100 per page instead of 10, which would reduce the impact of the issues David raises.

(More concise search result listings will also help with the user experience for large results -- less scrolling.)

— Reply to this email directly or view it on GitHub https://github.com/MutopiaProject/MutopiaWeb/issues/22#issuecomment-185337557 .

[glenl]

I recently moved this issue to the "Site Release #2" milestone which includes some reduction in browse results which, in turn, will probably result in a need to increase the number of results per page. I would like to keep pagination "alive" so it is eventually full-featured, but I am considering moving the issue out of this milestone since it is not my intent to add excessive complexity to the code base when this feature is essentially free in most web frameworks.

On no objections I will un-milestone this issue in 3 days.