视图层的作用_cad视图层设置_视图和表的区别

Ember.js拥有一个精心设计的用于创建、管理和渲染与浏览器的DOM连接在一起的具有层级的视图的系统。视图负责对用户输入做出响应，例如点击、拖动和滚动，还包括在视图底层数据发生改变时自动更新DOM的内容。

视图层级通常通过评估Handlebars模板来创建。子视图在评估模板的时候被添加。当这些子视图的模板被评估的时候，它们的子视图又被添加进来，如此反复，直到整个层级被创建出来。

即使没有显式的在Handlebars模板中创建子视图，Ember.js内部也会使用视图系统来更新绑定的值。例如，每个Handlebars表达式{{value}}会创建一个知道如何在其值改变的时候进行更新的视图。

使用Ember.ContainerView，可以在应用的运行期动态的改变视图的层级。与模板驱动不同，一个容器视图暴露了一组可以手动管理的子视图实例。

视图和模板联合提供了一个健壮的，可以创建任意梦寐以求的用户界面的系统。终端用户应该与诸如渲染和事件传播此类的复杂性隔离开来。应用开发者应该能一次性描述他们的UI，例如一串Handlebars标签，然后继续其应用而无需关心UI是否保持更新。

在一个典型的客户端应用中，视图可以表示DOM中互相嵌套的元素。本问题的一个最简单解决方案是分离表示每个DOM元素的视图对象，特定的引用可以帮助视图对象跟踪那些概念上嵌套在其中的视图。

下面是一个简单的示例，代表了一个应用的主视图，一个集合嵌套在其中，并且在集合中嵌套了各自独立的元素。

乍一看，这个系统似乎工作的非常好，但想像一下如果希望打开乔上午8点的Lamprey Shack取代9点的会发生什么。在这样的情况下，应用的视图需要重新新渲染，因为开发者需要构建基于一个特定基础的指向子视图的引用，而这个重新渲染的过程有许多问题。

为了重新渲染应用视图，应用视图必须手动的重新渲染子视图，并将子视图插入应用视图元素中去。如果实现的非常完美的话，重现渲染能工作的非常好，但是这个基于一个完美的、特定的视图层级的实现。如果任何一个视图没有实现的那么好，整个重现渲染将失败。

为了避免这些问题，Ember的视图层次一开始就烙下了子视图的概率。

当应用视图重新渲染的时候，Ember复杂重新渲染和插入子视图，而非应用代码。这意味着Ember可以执行内存管理，比如清除观察器和绑定。

这不仅消除了很多样板代码，而且也消除了没有实现的那么完美的视图层次在重新渲染时出现意想不到的错误的情况。

以前Web开发者为了知道用户与每个元素的交互，会在元素上添加事件器。例如，在一个<div>元素上注册一个函数，这个函数可以在用户点击<div>元素的时候被调用。

然而，当处理大量的交互元素的时候，这种方案往往不能扩展。例如，假设有一个<ul>元素，其包含了100个<li>在其中，每个元素都有一个删除按钮。由于对于这些元素来说都具有相同的行为，为每个删除按钮添加一个事件器这显然效率很低。

为了解决这个问题，开发者发现了一个被称为“事件委派”的技术。这种技术只在容器元素上注册一个器，然后使用event.target来判断是哪一个具体的元素被用户点击了，而不用为每一个元素添加一个器。

这样实现依然存在一些问题，因为有些事件（例如focus、blur和change）并不会冒泡。幸远的是，jQuery完全地解决了这个问题，jQuery的on方法支持所有的本地浏览器事件。

其 他的Javascript框架处理该问题通常有两种方法。第一种，需要自己实现一个简单的解决方案，即为每个元素创建一个独立的视图。当创建视图时，会给 每个视图元素添加一个事件器。如果一个列表包含500个元素，那么需要创建500个视图，并且每个视图将在其元素上绑定一个器。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-22614-1.html