5

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

我看过很多教程，人们解释了如何创建复杂和嵌套的视图，并且大多数人都部分地使用模板构建它，然后在父视图的渲染方法中，以便组合模板化的子视图

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

然而，我测试的所有模板框架都不允许创建带有嵌套视图的复杂标记。不能真正从模板调用模板并因此实例化 View 对象。这在技术上似乎是可行的，尤其是使用数据属性，我们可以在其中指定类型名称。

然后，根级 View 类的 render 方法所要做的就是把这个模板变成 HTML 标记，然后找出子对象的类型应该是什么，为其中的任何一个创建一个子视图实例，并进一步保持，如果这些子对象本身应该有子对象。每个视图都有一个模型上下文。基本上我们一直处理的所有样板步骤，但在 Backbone.View 级别自动化。

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

4

2 回答 2

1

需要注意的是，它根本不需要使用render，它主要是为代码更改后的重新渲染保留的。您可以直接基于 CSS 选择器绑定视图（参见文档）。

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

http://github.com/derickbailey/backbone.modelbinding

最后我会说这个关于渲染父子关系。 不要在循环中调用 DOM。这是非常低效的，这至少是人们只在父母渲染方法中建立父子关系的一个原因。让每个孩子使用说 jQuery 来呈现自己将为浏览器带来很多工作（如果您在现代浏览器中没有注意到这一点，请在 IE8 中尝试）。

于 2011-12-04T02:43:26.870 回答
1

我同意在该render方法中实例化子视图没有意义。尽管我会犹豫是否要完全自动化该过程，因为我经常想在初始化子视图时传递其他参数，例如：

var childCollection = someLogicToCreateTheChildCollection();

new ChildView({
  collection : childCollection
});

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

这样一来，我的渲染函数就不是声明 DOM 顺序的一个（就像许多通过附加显示的示例一样）——模板设置了 DOM 顺序，而渲染函数只是setElement().render()子视图。

于 2012-05-07T14:31:30.620 回答