Backbone-relational.js +主干.视图

Question

问题：文档很少，而且我是个菜鸟——任何人都可以确认将 Backbone.Views 绑定到 Backbone.RelationalModel 实例的正确（假设有一种）方法（来自backbone-relational.js) 用于更新/渲染到 dom？我尝试了一些基于 Backbone 中正常模型/视图绑定的不同方法，但收效甚微。

背景故事（/更多信息）： 我正在学习 Backbone.js 的诀窍，并且在过去的一周里学到了很多东西。如果我遗漏了一些明显的东西（这很可能 - 包括下面处理我的问题的“正确”方法），请给我打电话。

我正在处理一个 mongodb 支持的 REST 接口（我无法完全控制——或者我将在服务器端重新架构行为），它充分利用了嵌套字典，所以我一直在阅读如何在 Backbone 中最好地表示这一点（同时不破坏 Backbone 提供的出色的 save() + 服务器同步功能）。

我看到了两个选项： backbone-relational 和 ligament.js。

我从backbone-relational.js开始，并为树中的各种字典创建了RelationalModels（backbone-relational对Backbone标准模型的替代），这些字典由REST接口传回。它们之间的关系已定义，控制台记录每个模型（在各自的初始化函数中）的 JSON 显示它们都在整个集合级别上通过 fetch() 命令从服务器正确调用/加载。

所以，这一切都很棒。

问题：我有视图“监听”每个模型的更新（以及应该在 dom 上渲染模板的绑定函数），并且它们根本不会“触发”（更不用说渲染...）。主视图在 fetch() 上触发，没问题，加载“顶级”模型并将其渲染在 dom 上——但是表示“顶级”模型中的“外键”模型的视图永远不会这样做（即使数据肯定会加载到每个模型中，正如上面提到的每个模型上的控制台日志记录所证明的那样）。

任何见解将不胜感激。

直接回复下面的 Raynos 回复（感谢 Raynos！）： 如果我为 UpperLevelCollection 定义了一个基本 url，其中 UpperLevelModel 存在于服务器上的 (UpperLevelCollection url)/(UpperLevelModel id) 处，那么我如何将这些 LowerLevelCollections 映射到服务器端每个 UpperLevelModel 的一个 JSON 转储中的字典键？换句话说，是否可以在模型中使用集合正确处理来自服务器的数据转储（显然非常简单，但解决了问题）并正确保存/更新/同步回来？

[{
    "some_key": "Some string",
    "labels": ["A","List","Of","Strings"],
    "content": [{
        "id": "12345"
        "another_key": "Some string", 
        "list": ["A","list","of","strings"],
    },{
        "id": "67890"
        "another_key": "Some string", 
        "list": ["A","list","of","strings"],
    }],
}]

Answer 1

一般来说，对于嵌套字典，我采用以下方法：

var UpperLevelCollection = Backbone.Collection.extend({
    model: UpperLevelModel
  }),
  UpperLevelModel = Backbone.model.extend({
    initialize: function() {
      this.nested = new LowerLevelCollection;
    }
  }),
  LowerLevelCollection = Backbone.Collection.extend({
    model: LowerLevelModel
  }),
  LowerLevelModel = Backbone.Model.extend({});

将这些集合一直嵌套在模型中。

Answer 2

问题可能是，当您将新数据加载到 ParentModel 中时，您的子集合 AFAIK 实际上并未获取，而是被擦除并被新集合替换（请参阅backbone-relational.js 中第 584 行的 Backbone.HasMany.OnChange）。因此，您自己对子集合的绑定就消失了。

在我看来，这是骨干关系的一个弱点。此行为应该是可配置的，可以选择使用较慢的查找和更新方法而不是擦除和替换。