Pagination

[martinssipenko]

Added third (optional) parameter items_per_page to repositories method of organization class.

Issue #41

[dbu]

wrote a comment yesterday but seems github lost it :-(

anyways, i think that goes in a good direction. i will switch my project to this branch for now to not have the limit anymore.

i would however propose to make this an optional feature that can somehow be enabled. if you would fetch i.e. from the commits api without any range limits on a large project, this would totally explode. if people so far relied on the library to only fetch some commits, this would be a BC break.

ideally the user could configure the api with a custom limit (and 0 being no limit). if nothing is specified, the old behaviour would be kept.

even if one day somebody manages to expose the paging through the api in a good way, it still makes sense to have this automatic fetch-many-pages for convenience.

[martinssipenko]

Updated to not use recursion, instead we can make use of 'per_page' attribute, which is accepted by GitHub API.
Added third (optional) parameter items_per_page to repositories method of organization class.

$client->api('organization')->repositories($github_account, 'all', 100);

Note: There is a limit of maximum items per page - 100!

[dbu]

the problem with this is that it would be needed for all the get calls, not just repositories of organizations. if you can do that, i think it would be awesome (though check with a repo maintainer before doing that work).

i think here it would be valid to iterate over the results to do follow up requests if needed to get to the limit. you could make 2 parameters offset and limit, then the user can do paging himself (and detect if he hit the limit if count(results) == limit)