Pagination Customization

[avalara-stephen-hickey]

Currently, the only type of pagination available uses page and pageSize. There are other ways pages may want to be defined that are not available because of this implementation detail. For instance, it's impossible to get the same results if I wanted to paginate using top and skip (the Microsoft API Guidelines for client-side pagination). And it's impossible to convert from top and skip to page and pageSize because the result sets are different (due to integer division).

It's possible to make my own SieveProcessor to make this work, but there are a couple of issues with this.

1. I have to re-implement all of filtering/sorting when I really only want to change pagination.
2. The ISieveModel interface defines page and pageSize which may be unused if using a different sort method.

I think a quick fix to make this easier would be to make the ApplyPagination, ApplyFiltering, ApplySorting methods protected and virtual. This would let users inherit from SieveProcessor and only have to override the methods they care about changing. This fixes issue 1 and would not be a breaking change.

To fix issue 2, however, would probably be a breaking change, because it would require a change to ISieveModel, although would be a good path forward for the next major version. Changing the interface to use Skip and Take would allow more flexibility for both cases (you can convert skip/take => page/pageSize, but not vice versa), but I think implementing a pagination interface would be more ideal, because it could allow other types of paging as well, such as server driven pagination.

[ITDancer13]

I like the idea to simplify to derive from SieveProcessor by making ApplyPagination, ApplyFiltering, ApplySorting protected and virtual.

@Biarity, @hasanmanzak I think we should do this for version 2.5 as suggested --> Moved this request to #139

I'd like to use this discussion about if we plan to make Sieve compatible with top and skip.

[Biarity]

My take on this is that top/skip pagination is a completely different operation to page/size. It is also an operation that other develoeprs will certainly find useful to have, so I think it is a good idea to implement it as a core part of Sieve (see my comment #144).

In doing that though, do we allow both skip/top and page/size? Should they both be a part of the same ApplyPagination method? Should it be behind a feature flag in the config?

[ITDancer13]

If we want to support both I'd add two additional nullable integers top and skip to SieveModel. ApplyPagination should check that only page/size or top/skip are set:

• If both are set an exception should be thrown.
• If only page/size are set our current implementation should be called
• If only top/skip are set the new implementation should be called

What do you think about it? It would be a non breaking change which can be done right now with little effort and without need of additional configuration.

[Biarity]

I think this is a good way to go, nice and simple

[hasanmanzak]

Agreed!.

[ITDancer13]

Okay, I'll add it to the board and implement it as soon as possible :-)