Pagination about ember-django-adapter HOT 5 CLOSED

I solved this thus

App.ApplicationSerializer = DS.DjangoRESTSerializer.extend

  extractMeta: (store, type, payload)->
    if payload && payload.results && payload.count
      store.metaForType type, total: payload.count

  extractArray: (store, type, payload)->
    payload = if Ember.typeOf(payload) == 'array' then payload else payload.results
    @_super store, type, payload

from ember-django-adapter.

Thanks for the pointer @bortevik. We're already setting count as total in extractMeta:

https://github.com/dustinfarris/ember-django-adapter/blob/version-1.0/addon/serializers/drf.js#L25

We also set next and previous to the URLs from DRF but that's not useful. See the proposed solution below.

We also take care of results in extractArray:

https://github.com/dustinfarris/ember-django-adapter/blob/version-1.0/addon/serializers/drf.js#L68

This one is slightly different that what you do but it achieves the same result.

There is still an open question about how pagination should actually work with DRF from a high level. I just read the ember metadata docs (http://emberjs.com/guides/models/handling-metadata/) and it looks like they expect the server-side to implement a limit query param. Since the page size is set in the server-side code with DRF, we'll have to come up with something else.

Here are two options I've come up:

1. Set next and previous in extractMeta to the query params that would generate the next and previous pages. The next and previous metadata values would be accessed on the specific query with var meta = result.get("content.meta"); It would also be possible to access the metadata on the type with var meta = this.store.metadataFor("post");, however, only total would be accurate there. The values of next and previous in the type metadata wouldn't make sense. It might even be possible to remove the next and previous variables from the type metadata but I'm not sure.

2)Set a pageSize on the type metadata and manage the next and previous pages manually in applications.

Both options tie the application to DRF which isn't ideal but it's hard to avoid. To me it feels like option 1 is better because we're using something that DRF already gives us.

@bortevik / @dustinfarris What do you think of these two options? Can you think of any other options?

from ember-django-adapter.

Regarding the limit query param, is that an Ember requirement, or just an Ember suggestion? From that link you posted it looks like they just used it as an example. Either way, DRF already accepts a page_size query parameter to dynamically adjust the page size, and it looks like we could modify that easily in settings.py as described in the DRF docs if we had to:

REST_FRAMEWORK = {
  'PAGINATE_BY_PARAM': 'limit',
  ...

If limit is a requirement, we could add this setting example to the docs. (Speaking of which, we have been mentioning several things that should go in "the docs" but we don't really have any docs aside from the README. I'll open a separate issue to discuss this. edit: see #26)

Regarding the next/previous/count data, I like 'option 1', but I think the next/previous values are relevant even for the type metadata depending on the use-case (the user can decide whether to track pagination on the model or procedurally using the result). As a side note, I don't see why we need to change the name of "count" to "total" just because the example in the Ember docs uses "total". Is the "total" name actually required anywhere in Ember? If not, let's make a note to change that line—and, again, to make a nice example in the docs.

I don't really like the format of the value DRF returns for next/previous (e.g. "?page=2"). This isn't particularly useful for our needs. We could extract the numeric value, something like:

store.metaForType(type, {
  next: parseInt(payload.next.slice(6)),  // '?page=2' becomes 2
  ...

and then the rest is pretty straight-forward for the user:

...
  var meta = this.store.metadataFor('post');
  var moreResults = this.store.find('post', {
    pageSize: 10,
    page: meta.next
  });

(do query params hit our keyForAttribute method? if not, i guess that should be page_size: 10, or we'll need to decide whether we can/should decamilize query param keys)

from ember-django-adapter.

The limit query param and the total metadata variable is an Ember suggestion; I guess it's the defaults from Rails which seems to be used a lot in the Ember documentation. My initial thought was to try to support the examples in the Ember docs. The idea was to try to make it so an Ember app is independent of the ED adapter being used. But I'm not so sure that we should work too hard for that goal. In the end it's probably not possible for somebody to change from a Rails to a Django back-end (or vice versa) by just swapping out the adapter.

For page_size, I didn't know that DRF supported a dynamic page size so some of my thinking on this issue was misinformed.

I'll create a PR to change the pagination metadata to the DRF defaults (i.e. use count), extract the numeric values for next and previous and add documentation for page_size. I'll also add some integration tests to check if the query params are run through keyForAttribute and write the tests and documentation appropriately.

from ember-django-adapter.

This is being implemented via PR #38.

from ember-django-adapter.