我正在将Backbone.js用于涉及许多不同视图的应用程序,其中一些嵌套其他视图,而这些其他视图可能进一步嵌套其他视图。
此外,视图表示还取决于模型中的某些属性,例如,仅在用户已通过身份验证或其他类型的if-check时才显示某些内容
来自Adobe Flex的世界,我习惯于几乎完全使用标记来声明我的视图,甚至是深度嵌套或复合视图。 Flex使标记中的组件声明变得轻而易举。
我有点希望能够在纯视图表示和Backbone中的视图逻辑之间实现相同的分离,但是到目前为止,我一直在为此而苦苦挣扎。
其原因是,我绝不能仅使用模板来声明复合视图。因此,我不得不诉诸使用BB的render()方法实例化子视图并将其附加到父视图。可以...但是如果视图真的很细致,那么使用JS声明它们是一个过大的选择,因为我实际上最终会添加纯HTML字符串,这完全是一团糟。这意味着最好对这些模板使用模板,然后仅渲染模板而不是使用JS完成所有工作。
使用这两种方法只会破坏应用程序的任何一致性,但是我力求做到这一点,因为我已经阅读了很多(甚至是专业编写的)Backbone代码,而且我看到其他人也在为同一件事而苦苦挣扎。
如果我无法避免渲染方法的这种分离,那么至少我将必须确定应使用模板来渲染视图的某些边界,而不是或仅部分地。问题是这些标准是什么。
最佳答案
我的方法是将所有标记包含在模板中。
我对主干视图的概念是它们实际上是控制器。如果在更传统的Web应用程序框架中考虑Controller,则其工作是接收事件,封送模型,获取和呈现模板,传入模型并返回结果输出。
在骨干网中,视图是负责此任务的元素。但是,DOM不是输入/输出介质中的http,而是输入/输出介质。
因此,我认为视图是屏幕上UI特定区域的控制器。他们侦听事件,编组模型,获取和渲染模板,并因此修改DOM。
对我来说,何时去生成子视图而不是在循环中渲染模板的决定是相当宽松的。
如果可以在多个视图中使用它,我将在其中创建一个视图。
如果它有任何影响自己的事件或用户交互,但在“父”对象中没有任何影响,我将对其进行查看。
如果它有任何真正的逻辑,我将对其进行介绍。
如果它是相关的模型或集合,我将对其进行介绍。
但是,在任何一种情况下,视图都不会直接生成HTML-我将始终将标记存储在模板中。
关于javascript - 我应该在哪里使用模板,哪里应该以编程方式生成 View 对象?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/7307486/