javascript - 我应该在哪里使用模板，我应该在哪里以编程方式生成 View 对象？

Question

我正在将 Backbone.js 用于涉及许多不同 View 的应用程序，其中一些 View 嵌套其他 View ，而这些其他 View 可以进一步嵌套其他 View 。

View 的呈现也依赖于模型中的某些属性，例如，某些内容仅在用户已通过身份验证或其他类型的 if-check 时显示

来自 Adob​​e Flex 的世界，我习惯于几乎完全使用标记来声明我的 View ，甚至是深度嵌套或复合标记。 Flex 使标记中的组件声明变得轻而易举。

我有点希望我能在 Backbone 中实现纯 View 表示和 View 逻辑之间的相同类型的分离，但到目前为止我一直在努力解决这个问题。

原因是我无法仅使用模板来声明复合 View 。因此，我不得不求助于使用 BB 的 render() 方法来实例化 subview 并将它们附加到父 View 。这没关系……但是如果 View 变得非常细化，那么使用 JS 声明它们就太过分了，因为我实际上最终附加了纯 HTML 字符串，这完全是一团糟。这意味着最好为这些模板使用模板，然后只渲染模板而不是使用 JS 完成所有工作。

使用这两种方法只会破坏应用程序中的任何一致性，但我强制自己接受它，因为我已经阅读了很多(甚至是专业编写的)Backbone 代码，并且我看到其他人在努力解决同样的事情。

如果我不能避免这种渲染方法的分离，那么至少我将不得不设置任何特定的边界，哪些 View 应该用模板渲染，哪些不应该，或者只是部分。问题是这些标准是什么。

Answer 1

我的方法是将所有标记包含在模板中。

我对主干 View 的概念是它们实际上是 Controller 。如果您考虑更传统的网络应用程序框架中的 Controller ，它们的工作是接收事件、编码模型、获取和呈现模板、传入模型并返回结果输出。

在 Backbone 中， View 是负责此任务的元素。但是，输入/输出介质不是 http，DOM 是输入/输出介质。

因此，我认为 View 是屏幕上 UI 特定区域的 Controller 。它们监听事件、编码模型、获取和呈现模板，并作为结果修改 DOM。

何时去麻烦生成 subview 还是在循环中渲染模板，对我来说是相当宽松的决定。

如果它有可能在多个 View 中使用，我会从中创建一个 View 。

如果它有任何影响其自身的事件或用户交互，但实际上在“父”对象中没有任何影响，我会从中创建一个 View 。

如果它有任何真正的逻辑，我会从中得出一个观点。

如果它是一个相关的模型或集合，我会从中制作一个 View 。

但是，在任何这些情况下， View 都不会直接生成 HTML - 我将始终将标记存储在模板中。