Pager becomes long for large amount of pages

[cmckni3]

The pagination area can become large when paginating a table that contains many pages. Maybe we should show an ellipsis when pages is greater than say 15.

[cmbankester]

Yeah, this is true, though it's technically not a part of DataTable core. We could turn the pagination block in the example view into a mixin and implement it there

[ohadschn]

GMTA, I just thought of the same thing :)

I would argue that since DataTable already contains pagination-specific logic (e.g. gotoPage) it makes sense for it to support such "constrained" pagination.

Moreover, the way we bind to pages now is a bit hackish (ko foreach: {data: (new Array(pages()))} etc.). I think a proper pages (pure) computed would be nice where you could say something like:

<ul class="pagination" data-bind="foreach: pages">
    <li data-bind="css: class">
        <a href="#" data-bind="text: text, click: gotoAssociatedPage"></a>
    </li>
</ul>

Making it constrained (e.g. show N pages before and after current, where N is a ctor parameter) shouldn't be difficult. Support for "jumps" (e.g. go 10 forward) would be a nice touch as well.

[cmbankester]

@ohadschn I like that idea.

[ohadschn]

I've been doing some thinking about where the line should be drawn between the view and view model (VM). I believe the following observables should be dropped from the VM (knockout-datatable) and handled in the view (HTML):

• recordWord, recordWordPlural, and recordsText. These are pure view details and the simple logic logic in recordsText can be moved to the the view.
• unsortedClass, descSortClass, ascSortClass, and sortClass. CSS classes are also view details and the simple logic in sortClass can be moved to the view.
• leftPagerClass, rightPagerClass, and pageClass. Same as above, where each page in the proposed pages (observable) array above could have a current property the view could query and decide on the class (or just compare its index to currentPage).

What do you think?

[cmbankester]

I think those are great ideas, but I don't want to lose the easy access to these helper methods. Perhaps we could extract these methods into an opt-in extension of DataTable, e.g. by exposing a loadExtensions method on the DataTable object (or it's prototype).

[ohadschn]

I understand the temptation, but I think we should not give in to the dark side :)
Assuming we agree that these helper methods do not represent good practices, I posit that they simply should not be there as to not tempt the user. As an added bonus, we'll get a cleaner knockout-datatable code base.

[ohadschn]

@cmbankester any thoughts on this? BTW in the meantime it's pretty simple to implement on the view:

<!-- ko foreach: {data: (new Array(pages()))} -->
<li data-bind="visible:  Math.abs($index()+1-$parent.currentPage()) <= (4 + Math.max(0, 5-$parent.currentPage()) + Math.max(0, $parent.currentPage()+4-$parent.pages())), css: $parent.pageClass($index() + 1)">
    <a href="#" data-bind="css: 'fixed-page', text: $index() + 1, click: $parent.gotoPage($index() + 1)"></a>
</li>
<!-- /ko -->

fixed-page is necessary to prevent resizes when the amount of digits change (e.g. 9->10, 99->100):

.fixed-page {
    width: 50px;
    text-align: center;
}