2013-11-27 13 views
16

W jaki sposób można dokonać paginacji żądania powiązanych danych? Na przykład, jeśli moja Osoba ma tysiące modeli dołączonych do niego, jeśli zrobię co następuje, w myślenie RESTful, dostanę wszystkie z nich.w jaki sposób paginować relacje ember-data

var tasks = person.get('tasks'); 

To byłoby zbyt dużo danych. Jak zmusić niektóre parametry zapytania do żądania, które działa za kulisami? Idealnie do punktu końcowego z czymś podobnym dołączonym do końca.

?&offset=3&limit=3

Oto fiddle aby zilustrować to, co staram się osiągnąć w IndexController. Nie mam pojęcia, co to "ember way" ma robić stronicowane żądania używające danych ember.

+2

Czy kiedykolwiek wymyśliłeś dobre rozwiązanie tego problemu? – RyanJM

Odpowiedz

-2

Z poziomu Ember.js guides on using models można również przesłać zapytanie wraz z połączeniem find().

this.store.find('person', { name: "Peter" }).then(function(people) { 
    console.log("Found " + people.get('length') + " people named Peter."); 
}); 

od przewodnika:

Haszysz opcji wyszukiwania, które przechodzą do find() jest nieprzezroczysta Ember Danych. Domyślnie te opcje będą wysyłane na Twój serwer jako treść żądania HTTP .

Korzystanie z tej funkcji wymaga od serwera znajomości odpowiedzi na zapytania .

+0

dzięki za odpowiedź. tak, przeczytałem to. Problemem są moje punkty końcowe relacji zawarte w części 'links' moich ładunków. Gdybym chciał wszystkie "Zadania", użyłbym powyższej metody, ale jeśli chcę zapytać o zadania konkretnej osoby, mój punkt końcowy jest inny, 'ludzie/$ id/zadania' – David

+0

Z tego typu strukturą wydaje się "Osoba" powinna mieć relację 'tasks: hasMany ('task')', a następnie uzyskać dostęp do zadań konkretnej osoby za pomocą 'person.get ('tasks')'? – CraigTeegarden

+0

Mogę spróbować, ale zadania są polimorficzne w mojej aplikacji. Mogą należeć do osób lub firm. – David

10

on nie istniał, gdy kwestia ta została po raz pierwszy poprosił, ale teraz jest dodatek zwany ember-data-has-many-query, który wydaje w stanie, przynajmniej dla RESTAdapter i JSONAPIAdapter. Wygląda na to, że ma pewne dziwactwa ze względu na dane embers, które nie obsługują już stronicowania jako pierwszorzędnej koncepcji. Jeśli to Cię niepokoi, zawsze jest store.query, ale to wymaga Twojego API do obsługi (w twoim przykładzie) parametru filtru person_id na punkcie końcowym /tasks.

pokrewne:

(to nie wygląda to pytanie zaangażowanych JSON API, ale dyskusja jest istotna)

5

Jak dzisiaj nie ma jeszcze domyślny sposób obsługi stronicowania w ember.

Najpierw powinniśmy popatrzeć na prostszą rzecz, paginację z prośbą o numer findAll.

Można to zrobić z czymś .query({page:3}), ale prowadzi do pewnych problemów:

  1. Jest to dobre rozwiązanie dla klasycznych paginacji, ale przez nieskończone przewijanie nadal trzeba ręcznie połączyć wyniki.
  2. Wyniki nie są buforowane, więc posuwanie się do przodu i do tyłu na liście stronicowanej powoduje wiele zapytań. Czasami jest to konieczne, jeśli lista jest edytowalna, ale często jej nie ma.

Dla drugiego problemu buduję trochę addon called ember-query-cache, który podpina do sklepu i umożliwia buforowanie wyników zapytania. Bardzo krótkie demo jest dostępne here.

Teraz, jeśli mówimy o relacji Chciałbym szczerze polecam używać najwyższego poziomu .query aż masz lepsze wsparcie od samego ember-danych:

store.query('task', { person: get(person, 'id'), page: 3 } 

Nie ma nic złego o nim. Otrzymujesz swój wynik i utrzymujesz relację w innym kierunku. Działa bez ingerencji w dane ember, dopóki nie potrzebujesz buforowania, a jeśli potrzebujesz buforowania, to wymaga to tylko kilku hackowania, które zrobiłem w moim dodatku.

Nadal mamy nadzieję, że dane ember będą w pełni zgodne z JSONAPI, a to wymagałoby paginacji. Myślę, że z punktu widzenia interfejsu API najlepszą rzeczą byłoby mieć możliwość zapytania o następną i poprzednią stronę ManyArray zwróconą przez relację. Byłoby to wraz z JSONAPI, w którym zapewniony jest następny i poprzedni link. Ale aby to osiągnąć, trzeba by włamać się głęboko do danych ember, nie uzyskując znacznej poprawy w stosunku do najwyższego poziomu .query, z którego z powodzeniem korzystałem w wielu projektach.