When additional filters were provided for pagination like an expansion
or a predicate, they would not propagate to any call after the first.
This patch addresses that issue by storing all filters and moving them
to any new page objects being created.
Fixes#331.
Usage on a top-level collection:
```
Stripe::Customer.list.auto_paging_each do |customer|
puts customer
end
```
Usage on a subcollection:
``` ruby
customer.invoices.auto_paging_each do |invoice|
puts invoice
end
```
We've also renamed `#all` to `#list` to prevent confusion ("all" implies
that all resources are being returned, and in Stripe's paginated API
this was not the case). An alias has been provided for backward API
compatibility.
Fixes#167.
Replaces #211 and #248.
This makes ListObject behave a little more like an Array in that it gets
an #empty? helper. This should fit pretty well with the Enumerable
methods that it already has.
Replaces #193.
This pulls the `Enumerable` mixin into `ListObject`. There is some
question in pulls like #167 as to the future of `ListObject` and how it
might change when pagination is introduced, but because we're unlikely
to make any backward incompatible changes to the API, it's likely that
`ListObject` will continue to represent a page of data that's been
extracted from the API. Given that assumption, pulling `Enumerable` in
should be relatively safe.
Fixes#227.
Our list calls return their results wrapped in an object so that we
can include extra information. We use this, e.g., to include the URL
to query for more records in the Transfer#transactions sublist.
When you get a ListObject, if you want to actually manipulate it as a
list, you have to call `#data` first to get the actual underlying
list.
This adds an exception to the `#[]` method to make what's going on
clearer.
Fixes#68
