AKTUALISIEREN

Beachten Sie, dass diese Frage für die Beta-Version von Ember Data vor Version 1.0 gilt. Der Mechanismus zum Laden von Beziehungen über die URL hat sich nach der Beta-Version von Version 1.0 erheblich geändert!

Ich habe vor einiger Zeit eine viel längere Frage gestellt, aber da sich die Bibliothek seitdem geändert hat, werde ich eine viel einfachere Version fragen:

Wie benutzt du DS.Adapter.findHasMany ? Ich baue einen Adapter und ich möchte in der Lage sein, den Inhalt einer Beziehung auf get der Beziehungseigenschaft zu laden, und dies sieht wie die Art, es zu tun. Betrachtet man jedoch den Ember-Data-Code, sehe ich nicht, wie diese Funktion jemals aufgerufen werden kann (ich kann dies bei Bedarf in Kommentaren erläutern).

Es gibt keinen einfachen Weg mit meinem Backend, ein Array von IDs in den Property-Schlüssel in dem JSON aufzunehmen, den ich sende - der Serializer, den ich benutze, lässt mich nirgends einhaken, das zu ändern wäre auch rechenintensiv.

Es war einmal die Ember-Daten-Startseite, die ein Beispiel für das "Lazy Loading" zeigte ... Ist das möglich, oder ist das "Handle partially-loaded records" wie in der Roadmap angegeben, und kann nicht doch fertig sein.?

Ich bin auf API-Revision 11, Master-Zweig ab dem 15. Januar.

Aktualisieren

Okay, das Folgende funktioniert meistens. Zuerst habe ich die folgende Methode findHasMany in meinem Adapter basierend auf der Implementierung des Testfalls erstellt:

Voraussetzung dafür ist, dass Sie eine gut funktionierende extractId -Methode in Ihrem Serializer haben müssen, aber die eingebaute von RESTAdapter wird wahrscheinlich in den meisten Fällen funktionieren.

Dieses funktioniert , hat aber ein signifikantes Problem, das ich bei diesem Lazy-Loading-Ansatz noch nicht richtig verstanden habe: Wenn der ursprüngliche Datensatz vom Server neu geladen wird, alles geht in den Topf. Der einfachste Anwendungsfall, der dies zeigt, ist, wenn Sie einen einzelnen Datensatz laden, dann hasMany abrufen und dann alle die übergeordneten Datensätze laden. Zum Beispiel:

Im Fall von nur dem obigen Code passiert, dass wenn Ember Data den Datensatz re-materialisiert, er erkennt, dass bereits ein Wert im Datensatz war ( posts/1 ), versucht ihn erneut zu füllen, und folgt ein anderer Codepfad , der die URL-Zeichenfolge im JSON-Hash als ein Array von Einzelzeichen-IDs behandelt . Insbesondere wird der Wert von JSON an Ember.EnumerableUtils.map übergeben, wodurch die Zeichen der Zeichenfolge verständlicherweise als Array-Elemente aufgelistet werden.

Daher habe ich versucht, dies zu umgehen, indem ich DS.Model.hasManyDidChange "patche", wo dies geschieht, so:

(Vergiss es, das war eine wirklich schlechte Idee.)

Update 2

Ich fand, dass ich (mindestens) eine Sache mehr machen musste, um das oben erwähnte Problem zu lösen, wenn ein Elternmodell vom Server neu geladen wurde. Der Codepfad, in den die URL in einzelne Zeichen aufgeteilt wurde, war in DS.Model.reloadHasManys . Also überging ich diese Methode mit dem folgenden Code:

Damit ist die Verwendung URL-basierter hasManys fast verwendbar, mit zwei verbleibenden Hauptproblemen:

Erstens funktionieren die inverse belongsTo Beziehungen nicht korrekt - Sie müssen sie alle entfernen. Dies scheint ein Problem mit der Art zu sein, wie RecordArrays mit ArrayProxies ausgeführt werden, aber es ist kompliziert. Wenn der übergeordnete Datensatz neu geladen wird, werden beide Beziehungen zum "Entfernen" verarbeitet. Während also eine Schleife über das Array iteriert, entfernt der Zugehörigkeitscode zum Entfernen gleichzeitig Objekte aus dem Array, und dann flippt die Schleife aus, weil sie versucht, darauf zuzugreifen ein Index, der nicht mehr da ist. Ich habe das noch nicht herausgefunden, und es ist hart.

Zweitens ist es oft ineffizient - am Ende werde ich die hasMany vom Server zu oft neu laden ... aber zumindest kann ich das umgehen, indem ich ein paar Cache-Header auf der Serverseite sende.

Wenn jemand versucht, die Lösungen in dieser Frage zu verwenden, schlage ich vor, dass Sie den obigen Code zu Ihrer App hinzufügen, damit Sie schließlich irgendwo hinkommen. Aber das muss wirklich in Ember Data behoben werden, damit es richtig funktioniert, denke ich.

Ich hoffe, dass dies irgendwann besser unterstützt wird. Auf der einen Seite sagt die JSONAPI Richtung, die sie gehen, dass diese Art von Sache Teil der Spezifikation ist. Auf der anderen Seite hat Ember Data 0.13 (oder rev 12?) Das serialisierte Standardformat geändert, so dass Ihre URL in einer JSON-Eigenschaft namens *_ids ... sein muss, z. child_object_ids ... wenn es nicht einmal IDs gibt, die du in diesem Fall sendest! Dies scheint darauf hinzudeuten, dass die Verwendung eines Arrays von IDs in der Liste der Anwendungsfälle nicht hoch ist. Alle Ember Data-Entwickler, die das lesen: BITTE UNTERSTÜTZEN SIE DIESE FUNKTION!

Willkommen weitere Gedanken dazu!