虽然父视图直接为元素赋值,但是子视图则是延迟查找其元素的。子视图通过查找id与其elementId属性匹配的元素来完成对元素的赋值。除非显示的提供了elementId,否则渲染过程会生成elementId属性,并将该值赋给视图的RenderBuffer,这样视图就可以通过该属性来查找其元素。
在视图加入到DOM中之后,Ember和应用本身都可能想要重新渲染视图。这可以通过调用视图的rerender方法来触发重新渲染。
重新渲染将重复上述的第二和第三两个步骤,但存在两处不同:
与将元素插入到一个显式声明的特定地方不同,rerender将用一个新的元素替换已经存在的元素。视图层的作用
在渲染一个新的元素之外,将移除老的元素,并销毁其所有的子元素。这样Ember就可以在重新渲染视图时,自动的处理注销适当的绑定和观察器。因为注册和注销所有嵌套的观察器的过程都是自动的,这也使得观察器观察一个路径更为可行。
最常见的导致视图重新渲染的情况是绑定到Handlebars表达式({{foo}})的值发生改变。在内部,Ember为每个表达式创建了一个简单的视图,并在路径上注册了一个观察器。当路径发生改变时,Ember就会用新的值去更新DOM对应的部分。
另外一个常见的情形是{{#if}}或{{#with}}块。当渲染一个模板时,Ember为这些块助手创建了一个虚拟的视图。这些虚拟的视图并不会在公共的可见的视图层级部分出现(当从一个视图中获取parentView和childViews时),但是它们的存在可以保证重新渲染的一致性。
当被传递到{{#if}}和{{#with}}的路径发生改变时,Ember自动的重新渲染虚拟视图,这将替换其内容,更为重要的是,这将销毁所有子视图来释放内存。
在这些情形之外,应用有时也需要显式的重新渲染视图(通常是ContainerView,如下所示)。本例中,应用可以直接调用rerender,Ember会以相同的语义将重新渲染加入队列。
这个过程如下所示:

当Ember渲染一个模板化的视图时,将生成一个视图层级。假设有一个form模板。
并以如下方式加入到DOM中:
这将创建一个很小的视图层级,如下所示:

通过parentView和childViews属性可以游弋在这个视图层级中。
parentView的一个常见的使用场景就是在一个子视图的实例中。
为了在视图的生命周期中的不同点更加容易的执行操作,Ember提供了许多有用的钩子。
willInsertElement:本钩子在视图被渲染后,但还未插入到DOM中时被调用。它不访问视图的element。
didInsertElement:本钩子在视图一插入DOM后立即被调用。它可以访问视图的element,这在集成外部的库的时候尤为有用。任何显式的设置DOM代码都应该被限定在本钩子内。
willDestroyElement:本钩子在元素从DOM中移除之前调用。在此有机会来清理关联到DOM节点的一些外部状态。就像didInsertElement有助于集成外部库一般。
willClearRender:本钩子在视图被重新渲染之前调用。它可以在视图重新渲染之前做一些清理工作。
becameVisible:本钩子在视图的isVisible属性或者其某个父视图的isVisible属性变为真,且关联的元素变为可见之后调用。注意本钩子只适用于所有可见性都通过isVisible属性来控制的情况。视图层的作用
becameHidden:本钩子在视图的isVisible属性或者其某个父视图的isVisible属性变为假,且关联的元素变为不可见之后调用。注意本钩子只适用于所有可见性都通过isVisible属性来控制的情况。
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/jisuanjixue/article-22614-3.html
好心疼
12海里基本就确认了
实在是怀疑他有没有真才实学