Ich fange gerade mit Backbone an. Ich habe die ersten beiden PeepCode-Screencasts durchgesehen, die großartig waren, und jetzt greife ich auf ein kurzes (nicht serverseitiges) Modell einer zukünftigen App zurück.
Hier ist, was ich (grob) bauen möchte. Eine Reihe von fünf Textfeldern - lassen Sie diese Widgets aufrufen. Jede Widget-Eingabe, wenn ausgewählt, zeigt einen Bereich an, der Aufgaben anzeigt, die mit dem Widget verknüpft sind und es dem Benutzer erlauben, eine neue Aufgabe zu erstellen oder bestehende Aufgaben zu zerstören.
An diesem Punkt denke ich, dass ich die folgenden Modelle habe:
%Vor%Die folgenden Sammlungen:
%Vor%Die folgenden Ansichten (hier wird es haarig!)
%Vor%Unter der Annahme, dass dies sinnvoll ist, besteht der Trick darin, eine TaskPaneView anzuzeigen, wenn eine WidgetView ausgewählt ist. Außerdem sollte TaskPaneView TaskCreateViews und TaskListViews anzeigen.
Die eigentliche Frage ist: Führt eine Kaskade Ereignisse über Ansichten hinweg? Ist es einer Root-Ansicht erlaubt, Unteransichten zu kennen und sie explizit zu rendern? Sollte dies ereignisgesteuert sein?
Entschuldigung, wenn das eine offene Frage ist, nur zu hoffen, dass jemand schon einmal etwas Ähnliches gesehen hat und mir in die richtige Richtung zeigen kann.
Danke!
Definiere es definitiv ereignisgesteuert. Versuchen Sie auch, keine eng gekoppelten Ansichten zu erstellen. Lose Kopplung macht Ihren Code wartbarer und flexibler.
Lesen Sie diesen Beitrag zum Ereignisaggregatormodell und Backbone:
In der kurzen Version können Sie das tun:
%Vor%und verwenden Sie vent.trigger und vent.bind, um Ihre App zu steuern.
Vorwort: Ich habe mit dem Code, den ich unten geschrieben habe, einen Sinn für dich gemacht: Ссылка
Ich stimme dem pub / sub ("Beobachtermuster") zu, das von den anderen Antworten vorgeschlagen wird. Ich würde aber auch die Leistung von Require.js zusammen mit Backbone nutzen.
Addy Osmani hat ein paar GROSS geschrieben! Ressourcen zu Javascript Design Patterns und zum Erstellen von Backbone-Anwendungen:
Das coolste an der Verwendung von AMD (implementiert in Require.js) zusammen mit Backbone ist, dass Sie ein paar Probleme lösen, die Sie normalerweise hätten.
Normalerweise werden Sie Klassen definieren und diese in einer Art Namensraum speichern, z. B .:
%Vor% Das ist in Ordnung, solange Sie die meisten Dinge in einer Datei definieren, wenn Sie mehr und mehr verschiedene Dateien zum Mix hinzufügen, wird es weniger robust und Sie müssen darauf achten, wie Sie in verschiedene Dateien laden, controllers\Tasks.js nach models\Task.js etc. Sie könnten natürlich alle Dateien in der richtigen Reihenfolge kompilieren, aber es ist bei weitem nicht perfekt.
Hinzu kommt, dass das Problem mit der Nicht-AMD-Methode darin besteht, dass Ansichten enger ineinander geschachtelt werden müssen. Sagen wir:
%Vor%Alles gut und gut, aber das kann ein Albtraum werden.
Mit AMD können Sie ein Modul definieren und ihm ein paar Abhängigkeiten geben, wenn Sie interessiert sind, wie das funktioniert, lesen Sie die obigen Links, aber das obige Beispiel würde so aussehen:
%Vor%Beachten Sie, dass ich im Fall von Ansichten, die Sie Instanzen zurückgeben, dies auch für Sammlungen tun würde, aber für Modelle würde ich Klassen zurückgeben:
%Vor%Das mag auf den ersten Blick ein bisschen zu viel sein, und die Leute mögen denken "Wow, das ist Overkill". Aber die wahre Macht wird deutlich, wenn Sie die gleichen Objekte in vielen verschiedenen Modulen verwenden müssen, zum Beispiel Sammlungen:
%Vor%Beachten Sie, dass das "Aufgaben" -Objekt in beiden Ansichten genau gleich ist, also die gleichen Modelle, den gleichen Zustand usw. Das ist viel schöner, als Instanzen der Tasks-Sammlung an einem Punkt zu erstellen und dann über die ganze Anwendung die ganze Zeit.
Zumindest für mich mit Require.js mit Backbone hat ein gigantisches Stück des Puzzles weggenommen, wo was zu instanziieren. Die Verwendung von Modulen ist sehr hilfreich. Ich hoffe, dies gilt auch für Ihre Frage.
ps. Bitte beachten Sie auch, dass Sie auch Backbone, Underscore und jQuery als Module in Ihre App einbinden, obwohl Sie dies nicht tun müssen. Sie können sie einfach mit den normalen Skript-Tags laden.
Für etwas mit dieser Art von Komplexität könnte ich empfehlen, Backbone Aura zu verwenden, das noch keinen stabilen hatte Release-Version. Aura ermöglicht es Ihnen, mehrere vollständig eigenständige Backbone-Apps, sogenannte "Widgets", zu verwenden, die auf einer einzelnen Seite ausgeführt werden. Dies kann helfen, einige Ihrer Modell- / Ansichtslogiken zu entwirren und zu glätten.
Aus einer klassischen MVC-Perspektive reagieren Ihre Ansichten auf Änderungen in ihren zugeordneten Modellen.
%Vor%Die Idee hier ist, dass jedes Modell einer Ansicht geändert wird, wird es sich selbst rendern.
Alternativ oder zusätzlich können Sie, wenn Sie etwas in einer Ansicht ändern, ein Ereignis auslösen, auf das der Controller hört. Wenn der Controller auch die anderen Modelle erstellt hat, kann er sie auf sinnvolle Weise modifizieren. Wenn Sie auf Änderungen an den Modellen achten, ändern sich auch die Ansichten.
Ähnliche Antwort auf Chris Biscardi's. Folgendes habe ich:
Sie erstellen einen globalen var Dispatcher (muss nicht global sein, solange auf den Bereich der Backbone-App zugegriffen werden kann):
%Vor%Der Dispatcher hilft Ihnen, abonnierte Rückrufe mit Ereignissen auszuführen, die nicht besonders durch Änderungen in Modellen oder Sammlungen ausgelöst werden. Und cool ist, dass der Dispatcher jede Funktion innerhalb oder außerhalb der Backbone-App ausführen kann.
Sie abonnieren Ereignisse mit bind () in einer Ansicht oder einem beliebigen Teil der App:
%Vor%In einer anderen Ansicht oder einem Teil der App triggern Sie ein neues Ereignis mit trigger ():
%Vor%Das Schöne an der Verwendung eines Dispatcher ist die Einfachheit und Fähigkeit, mehrere Listener (z. B. Rückrufe in verschiedenen Backbone-Ansichten) für dasselbe Ereignis zu abonnieren.
Tags und Links backbone.js