Question

我敢称自己为骨干黑客。我知道框架可以做什么，以及它的局限性。我也有一些模板框架的经验。

我已经看过许多教程，其中人们解释了如何创建复杂和嵌套的视图，并且大多数教程构建它有点使用模板，然后在父视图的render方法中，以组合模板化的子视图

对我而言，在声明性代码中，为什么应该处理布局渲染是没有意义的。来自Flex，我被教导永远不会这样做。我总是将布局描述和变量绑定留给标记，然后将事件处理留给使用此标记的声明性（View实例）代码。

但是，我测试的模板框架都不允许使用嵌套视图创建复杂标记。实际上无法从模板调用模板，因此实例化View对象。这似乎在技术上是可行的，特别是使用数据属性，我们可以在其中指定类型名称。

然后，根级View类的所有渲染方法都要将此模板转换为HTML标记，然后找出子对象的类型应该是什么，为它们中的任何一个创建子视图实例，以及如果这些子对象本身应该有子对象，请继续保持。每个视图都有一个模型上下文。基本上我们一直处理的所有样板步骤，但在Backbone.View级别自动化。

有人在想这个吗？为什么似乎没有人使用它？

Answer 1

应该注意的是，根本不需要使用渲染，并且主要是在对代码进行更改之后保留用于重新渲染。您可以直接基于CSS选择器绑定视图（请参阅相关文档）。

此外，Backbone还有一个模型绑定扩展，极大地简化了数据绑定并减少了所需的“手动”劳动力。你可能想看一下。

最后，我将谈论渲染父子关系。 Do not call the DOM in a loop。这非常低效，至少有一个原因是人们只会在父渲染方法中建立父子关系。让每个孩子使用say jQuery渲染自己将导致浏览器的大量工作（如果你在现代浏览器中没有注意到这一点，请在IE8中尝试）。

Answer 2

我同意在render方法中实例化子视图毫无意义。虽然我对完全自动化该过程犹豫不决，因为我经常想在初始化子视图时传入额外的参数，例如：

var childCollection = someLogicToCreateTheChildCollection();

new ChildView({
  collection : childCollection
});

所以，我最终要做的是在initialize中创建我需要的任何子视图，然后在render中创建模板并将子视图分配给DOM中的元素。

这样我的渲染函数就不是声明DOM顺序的那个（就像通过追加显示的很多例子一样） - 模板设置DOM顺序，渲染函数只是setElement().render()的子视图。 / p>