backbone.js - collections et vues

Je comprends comment obtenir une collection, ou un modèle individuel. Et je peux habituellement obtenir un modèle de données à afficher. Mais je ne suis pas clair du tout comment faire une collecte et d'obtenir la liste des modèles dans cette collection pour afficher.

Suis-je censé effectuer une itération sur la collecte et le rendu de chaque modèle individuellement?
Est censé être une partie de la collection de la fonction rendu?

Ou la collection de disposer de son propre point de vue et de toute façon je remplir la totalité de la collecte de données en vue?

Juste en parlant de façon générale, quelle est la méthode normale pour afficher une liste de modèles?

source d'informationauteur Matthew | 2011-04-13

De mon expérience, c'est le meilleur à garder dans votre collection d'afficher les références de chaque modèle.

Cet extrait du projet que je suis en train de travailler sur devrait vous aider à obtenir l'idée de mieux:

var MyElementsViewClass = Backbone.View.extend({
    tagName: 'table',

    events: {
        //only whole collection events (like table sorting)
        //each child view has it's own events
    },
    initialize: function() {
        this._MyElementViews = {}; //view chache for further reuse
        _(this).bindAll('add');
        this.collection.bind('add', this.add);
    },
    render: function() {
        //some collection rendering related stuff
        //like appending <table> or <ul> elements

        return this;
    },
    add: function(m) {
        var MyElementView = new MyElementViewClass({
            model: m
        });

        //cache the view
        this._MyElementViews[m.get('id')] = MyElementView;

        //single model rendering
        //like appending <tr> or <li> elements
        MyElementView.render(); 
    }
});

Prenant cette approche permet de mettre à jour les vues de manière plus efficace (re-rendu d'une ligne dans la table, au lieu de l'ensemble de la table).

8

Je pense qu'il y a deux façons de le faire.
- Utiliser un affichage par article, et de manipuler le DOM vous-même. C'est ce que l'Todos exemple. C'est une belle façon de faire les choses parce que la gestion des événements pour un seul élément de modèle est plus clair. Vous pouvez également faire un modèle par élément. Sur le revers de la médaille, vous n'avez pas de modèle unique pour l'affichage de la collection dans son ensemble.
- Utiliser une vue de l'ensemble de la collection. Le principal avantage ici est que vous pouvez faire plus de manipulation de vos modèles. L'inconvénient est que vous n'avez pas de modèle par élément, donc si vous avez une collection hétérogène, vous avez besoin pour passer à l'affichage de la collection de code de modèle -- bletcherous.
Pour la deuxième stratégie, j'ai fait un code qui fonctionne quelque chose comme ceci:
```
var Goose = Backbone.Model.extend({ });

var Gaggle = Backbone.Collection.extend({
   model: Goose;
};

var GaggleView = Backbone.View.extend({
    el: $('#gaggle'),
    template: _.template($('#gaggle-template').html()),
    render: function() {
        $(this.el).html(this.template(this.model.toJSON()));
    }
};

var g = new Gaggle({id: 69);

g.fetch({success: function(g, response) {
    gv = new GaggleView({model: g});
    gv.render();
}});
```
Le modèle de code devrait ressembler à quelque chose comme ceci:
```
  <script type="text/template" id="gaggle-template">
  <ul id="gaggle-list">
  <% _.each(gaggle, function(goose) { %>
     <li><%- goose.name %></li>
  <% }); %>
  </ul>
  </script>
```
Noter que j'utilise le _ fonctions (utile!) dans le modèle. J'utilise aussi le "obj" élément, qui est capturé dans la fonction de modèle. C'est probablement triche un peu, en passant dans {troupeau: [...]} pourrait être plus agréable, et moins dépendante de la mise en œuvre.

Je pense que quand il descend à lui, la réponse est "Il y a deux façons de le faire, et ni l'un, c'est la grande."
3

L'idée de base est que le rendu de l'affichage est basé sur l'événement.

Vues joindre à Modèle de données d'événements de changement de sorte que lorsque toutes les données dans le modèle, la vue change et se met à jour pour vous.

Ce que vous êtes censé faire avec des collections est de manipuler un ensemble de modèles en même temps.

Je vous recommande de lire les annoté exemple.
0

J'ai aussi trouvé cette confusion partie de l'épine Dorsale du cadre.

L'exemple Todos code est un exemple ici. Il utilise 4 classes:
- Todo (s'étend de la colonne vertébrale.Modèle). Cela représente un seul élément à être todone.
- TodoList (s'étend de la colonne vertébrale.De la Collection). Son "modèle" de la propriété est la tâche de la classe.
- TodoView (s'étend de la colonne vertébrale.La vue). Son nom de balise est "li". Il utilise un modèle pour le rendu d'une seule Todo.
- AppView (s'étend de la colonne vertébrale.La vue). Son élément est le "#todoapp" . Au lieu d'avoir un "modèle" de la propriété, il utilise un mondial TodoList nommé "Todos" (on ne sait pas pourquoi...). Il se lie à la modification importante des événements sur Todos, et quand il y a un changement, il ajoute qu'une seule TodoView, ou une boucle par tous les Todo cas, l'ajout d'un TodoView à la fois. Il n'a pas un modèle unique de rendu; il permet à chaque TodoView rendu de lui-même, et il a un gabarit pour le rendu, les statistiques de la zone.
Ce n'est pas vraiment le meilleur du monde exemple pour le premier examen. En particulier, il ne doit pas utiliser le Routeur de classe à la route des Url, ni ne carte les classes du modèle de REPOS ressources.

Mais il semble comme la "meilleure pratique" peut être de conserver une vue pour chaque membre de la collecte et de manipuler le DOM éléments créés par ces points de vue directement.

Vous devez vous connecter pour publier un commentaire.