Y at-il une raison pour laquelle je devrais éviter cela dans Backbone.js?

Question

Je jouis Backbone.js de plus en plus. Je désire avoir plusieurs vues pour un modèle donné:

• Une liste vue où chaque modèle a une vue avec son propre élément li.
• Une vue détaillée montrant tous les détails d'un modèle.

Ma question est, je cherchais un bon moyen pour permettre une vue de communiquer avec un autre et élu comme suit:

/** Allow a model to keep track of it's views. **/
Backbone.Model.prototype.addView = function (view) {
    // Ensure our model has a view array.
    if (typeof this.views === 'undefined')
    {
        this.views = [];
    }

    // Append our newest view to the array only if it is not already present.
    if (_.indexOf(this.views, view) === -1)
    {
        this.views.push(view);
    }
}

/** Allow a model to remove all of it's views.
 * 
 * @param {Object} args Any arguments will be provided to the view's method.
 */
Backbone.Model.prototype.unloadViews = function (args) {
    var n = (typeof this.views === 'undefined') ? 0 : this.views.length;
    for (var i = 0; i < n; i++)
    {
        var view = this.views[i];
        if (typeof view.unloadView === 'function')
        {
           view.unloadView(args);
        }
    }
}

/** Allow a model to re-render all of it's views.
 * 
 * @param {Object} args Any argyments will be provided to the view's method.
 */
Backbone.Model.prototype.renderViews = function (args) {
   var n = (typeof this.views === 'undefined') ? 0 : this.views.length;
   for (var i = 0; i < n; i++)
   {
        var view = this.views[i];
        if (typeof view.render === 'function')
        {
            view.render(args);
        }
   }
}

Mes questions

1. Am quelque chose que je manque que j'apprends Backbone.js qui me permettra de le faire nativement?
2. Y at-il une raison que je dois éviter cela?

Informations supplémentaires

Je partage l'application (assez rudimentaire) sur GitHub: https://github.com/ aarongreenlee / apprentissage Backbone.js . Si vous préférez voir le code dans cet environnement, vous pouvez y accéder ici:

Était-ce utile?

Nous faire parvenir

La solution

Eh bien votre point de vue peut avoir un arbre comme référence, mais votre modèle devrait pas connaître votre point de vue!

Vous devez définir vos vues à écouter les événements de changement des modèles et réagissent en conséquence ont (re rendu c'est).

Vous évitez ainsi des références croisées entre les parties inférieures de votre logiciel (celui qui doit être solide comme le roc, le modèle) et les parties les plus élevées, les points de vue. séparation classique MVC.

Alors déplacez vos addViews, removeViews à Backbone.View et il devrait être bon. Vous allez créer un système de vue hiérarchique, un peu comme ce que SproutCore offres.

Amusez-vous!

Answer 1

Eh bien votre point de vue peut avoir un arbre comme référence, mais votre modèle devrait pas connaître votre point de vue!

Vous devez définir vos vues à écouter les événements de changement des modèles et réagissent en conséquence ont (re rendu c'est).

Vous évitez ainsi des références croisées entre les parties inférieures de votre logiciel (celui qui doit être solide comme le roc, le modèle) et les parties les plus élevées, les points de vue. séparation classique MVC.

Alors déplacez vos addViews, removeViews à Backbone.View et il devrait être bon. Vous allez créer un système de vue hiérarchique, un peu comme ce que SproutCore offres.

Amusez-vous!

Answer 2

Une réponse est venu de Twitter de Jeremy Ashkenas du document Nuage

  

@aarongreenlee Aucune raison pour l'éviter   - si vous voulez avoir votre point de vue de conserver une référence à l'arbre comme l'autre,   c'est certainement légitime. - @ jashkenas