addyosmani/backbone.paginator — pull request #132 by willsu (2013-01-29 23:13:28+00:00)
Title: Pager interface unification

#### This pull request is regarding the following issue:
https://github.com/addyosmani/backbone.paginator/issues/125

#### The (verbose) comment for this commit is as follows:
'Unified' the interfaces of some common public methods between clientPager and requestPager: nextPage(options), prevPage(options), goToPage(pageNum, options). In Paginator.requestPager, simply aliased the 'requestNextPage' and 'requestPreviousPage' functions to 'nextPage' and 'prevPage' respectively. In Paginator.clientPager modified 'pager' function to accept 'options' param and trigger a 'success' function defined in the options. Unified the variable names from 'previous', 'next' (clientPage) and 'hasPrevious' , 'hasNext' (requestPager) information object to 'previous', 'next'.

### Additional Details:
This change unifies the interfaces between clientPager and requestPager to the extent that the same Backbone view can use them interchangeably. This change does not make (or hinder, afaik) any progress towards Backbone 1.0 compatibility. Some functions in the client and request pagers were aliased to maintain backwards compatibility with the Backbone.Paginator library.

Probably the biggest 'hack' here is at the end of the clientPager.pager function.

Lines 328-330 of backbone.paginator.js
```javascript
if (!_.isUndefined(options) && !_.isUndefined(options['success'])) {
options['success']();
}
```
I did this because I haven't yet had the chance to dig into the implication of getting this options passed down and evaluated by the Backbone.Collection.reset method. If someone has a clear path on a better way to handle this particular piece of code please let me know.

That said, I also couldn't come up with any realistic failure scenarios for clientPager failure. On the requestPager, the options get passed into the Backbone.Collection.fetch function and the 'error' callback will be invoked when a non-200 series response gets returned from the server. For the clientPager, I could have added some exception handling(?) and invoke the error method when an exception is caught. However it may not be terribly important to support an error callback for clientPager functions that invoke '.pager' function. Also, the success method on the clientPager will be invoked with empty args, as opposed the response arguments, etc., passed in by Backbone in the requestPager (which is really another interface disparity, but it still brings us closer).

I ended up aliasing the 'hasPrevious' and 'hasNext' properties of the 'information' object in the requestPager to 'previous' and 'next'. I know that these properties aren't really considered to be public, but they were convenient to use in my view to determine pagination boundaries. Perhaps we can consider making some formal public methods '.next' and '.previous' live off of the collection itself.

I also refactored some various test cases in the suite.

Please let me know if there's anything that I can change and/or clean up. Thanks!