Client pager startRecord calculation bug?

[dgs700]

var start in Paginator.clientPager.pager() and

info.startRecord in Paginator.clientPager.info()

do not seem to be calculated correctly when you select a page number near the end of the list and then select a higher show-X records that would run off the end of the list.

To recreate in the clientPager() example, select page 9 then select show 12 per page.

Love the rest of paginator as it was the missing piece to the Backbone app I'm currently working on.

[addyosmani]

Confirmed. Thanks for the heads up! I'll get this fixed up as soon as possible.

[addyosmani]

I've been looking at this problem this evening and there are a few different options we have available to us. To provide some background information on what is happening:

Say we have 30 results in total with 3 results shown per page. When you navigate to a page N (e.g 9) and then set the number of records to display per page to M (e.g 12), your current paged page is no longer valid as there would only be a maximum of 3 pages available for a user to browse to. This is why nothing displays when you land on the page.

Our options for what to do here are as follows:

• When a user changes the number of results to display per page, reset the pagination completely so that they must start browsing from the first page of results
• Attempt to determine what new page the set of results they were previously viewing is now on (e.g for page 9, this would probably be page 3) and then show them this page.

@dgs700 which of these makes the most sense to you?

[addyosmani]

Just to note: pagination systems like eBay appear to reset so the user must browse from the first page

[addyosmani]

I just pushed a patch which resets you to the first page of the set if you change the number of results to display per page. This falls in line with how other pagination systems appear to approach the problem. If you agree with the fix, I'm happy to close this issue.

[dgs700]

I had actually hacked it to do option 1. For my use case there typically will always be a low number of records (<100) and having pagination capability on the page is not a critical function, so just resetting to page 1 works for me. So its a closed issue from my standpoint.

Option 2, recalculating the current page and then going from there, would probably be the solution that would satisfy the developer who is really anal about having their pagination work on any change from any point in the record set. I'm not one of those, but if I was providing a paginator, I would probably shoot for having the option 2 functionality at some point just so I wouldn't have to hear from them. My two cents on that.

Thanks!

[addyosmani]

Thanks for the feedback @dgs700!. I think supporting option 2 is definitely something I'll consider for the future. For now, as option 1 seems to solve what i imagine most people will be after, I'll close it.

Appreciate you pointing this out once again!