ExtJS 4的组件机制

组件、容器是ExtJS组件机制的基础，后者是前者的子类型。

这是一个ExtJS框架的私有混入，定义了组件渲染的核心逻辑，对于下面这个包含三层嵌套的Panel：

Renderable定义其渲染过程如下：

1. ContainerA被初始化时转调父类构造器，在AbstractComponent.constructor()中，由于配置了renderTo，调用render()方法，进入渲染阶段
2. render()开始渲染ContainerA，首先禁用布局系统，然后调用getRenderTree()，获取“渲染树”，这个所谓的渲染树就是一个DomHelper规格对象
3. getRenderTree()触发事件beforerender、调用beforeRender()模板方法，然后调用getElConfig()获取渲染树对象
4. 根据是否配置外框（Window、Tip必须有外框），getElConfig()会生成不同的结果：要么调用initFramingTpl()，要么调用initRenderTpl()生成一个模板，并置入渲染树：{tag : 'div', tpl: template}的tpl属性
   1. 从细节上看，initRenderTpl()获取当前类（Container）的renderTpl属性作为tpl，该模板具有以下成员：
      

      属性	说明
      html	容器的HTML结构，整体形式如下： XHTML 1 {% this.renderDockedItems(out,values,0); %} {%this.renderContainer(out,values);%} XHTML 1 {% this.renderDockedItems(out,values,1); %}
      initialConfig	传入的初始配置对象
      renderBody	可供在模板中调用的一系列方法 这些xxx方法都是在： Renderable.setupFramingTpl() AbstractContainer.setupRenderTpl() 等方法中，与容器、布局类的doXxx进行关联得到的。之所以要和布局类的doXxx关联，是因为布局才知道子组件如何渲染
      renderContainer
      renderContent
      renderDockedItems
      renderItems
      renderPadder

   2. 如果配置了autoEl，替换渲染树的tag属性
   3. 调用initRenderData生成tpl的填充上下文（tplData），并提供一些默认值
   4. 最终返回的渲染树形式如下（符合DomHelper规格约定）：
      
      JavaScript

      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

      {     tag: "div",     cls: "",     style: {         height: "500px"         width: "500px"     },     id: "ContainerA"     tpl: {         html: "..."         initialConfig: {}         renderBody: function (out, renderData) {...}         renderContainer: function (out, renderData) {...}         renderContent: function (out, renderData) {...}         renderDockedItems: function (out, renderData, after) {...}         renderItems: function (out, renderData) {...}         renderPadder: function (out, renderData) {...}     },     tplData : {         $comp: '当前组件'         baseCls: "x-panel"         bodyCls: "x-panel-body-default"         bodyStyle: ""         componentCls: "x-panel"         frame: undefined         id: "ContainerA"         ui: "default"         uiCls: []     } }

5. render()得到渲染树后，使用DomHelper将其插入到文档中，一旦插入，整个组件（包括所有后代组件）的DOM结构就都生成了，结果如下：
6. 插入DOM完毕后，render()设置ContainerA的el为新生成的HTML元素ContainerA
7. render()调用finishRender()完成渲染阶段，在此阶段，会自上而下的递归调用所有子代组件的onRender()，然后自下而上的递归完成所有子代组件的afterRender()调用，需要注意的是，子代的onRender()完全处于父代的afterRender()调用的内部
   1. 调用onRender()
      1. 设置renderSelectors为成员变量
      2. 清除正在渲染状态：rendering，设置rendered=true
      3. 记住lastBox={width:500,height:500}
   2. 设置targetEl的overflow样式；设置封装元素的visibilityMode
   3. 如果有存在监听器，则发布render事件
   4. 调用afterRender()，该方法最终会触发布局，主要逻辑位于Rendererable中
      1. 调用finishRenderChildren()完成子代的渲染
         1. 组件布局渲染：调用Renderable.finishRenderChildren()渲染内部结构
            1. 获取组件布局getComponentLayout()，这里是Ext.layout.component.Dock
            2. 调用Dock.finishRender(),该方法会获取dockedItems，并调用Ext.layout.Layout.finishRenderItems()逐个渲染
         2. 容器布局渲染：调用AbstractContainer.finishRenderChildren()渲染子组件
            1. 获取容器布局getLayout()，这里是Ext.layout.container.HBox
            2. 调用HBox.finishRender()，后者转调父类（Ext.layout.container.Container）版本
            3. Container.finishRender()获取渲染目标（targetEl）和渲染子组件（仅一个ContainerB）
            4. 调用Container.finishRenderItems(target, items)完成子组件渲染
            5. 转调Ext.layout.Layout.finishRenderItems()，逻辑类似7.4.1.1
               1. 调用ContainerB的Renderable.finishRender，这一小节是类似于7的递归调用
                  1. 子组件ContainerB的el属性被设置，不再为空
                  2. 调用ContainerB的onRender模板方法，逻辑类似7.1，lastBox为250
                  3. 调用ContainerB.afterRender()
                     1. finishRenderChildren()
                     2. 完成组件布局渲染（Dock）
                     3. 完成容器布局渲染（Fit），继续递归用
                        1. ComponentA.finishRender()
                           1. ComponentA.onRender()
                           2. ComponentA.afterRender()
                              1. ……一直递归到最底层组件……
                     4. 由于不是顶层容器，不进行updateLayout()
                  4. 如果有存在监听器，则发布afterrender事件
                  5. 初始化事件：initEvents()
                  6. 如果配置为隐藏，那么调用getEl().hide()
            6. 对于每一个item，调用afterRenderItem(item)
      2. 为targetEl添加CSS类styleHtmlCls、增减样式
      3. 由于当前容器是顶层的，调用AbstractComponent.updateLayout()触发布局
         1. 如果当前组件是隐藏的，调用cancelLayout()取消布局
         2. 否则判断是否布局根，如果不是，什么都不做
         3. 由于ContainerA的布局未被暂停，调用静态函数Ext.AbstractComponent.updateLayout执行实际布局逻辑。这里可以看到，AbstractComponent类对象是全局的布局管理对象，updateLayout会把参数指定的组件放入某个队列，并且进行复杂的布局计算
            1. 如果当前正在运行布局，则把ContainerA放入running的无效队列
            2. 如果当前没有运行布局，则把ContainerA放入pending的无效队列，这里匹配这一条
               1. 如果当前布局系统没有被暂停，则立即刷新布局flushLayouts()
   5. 如果有存在监听器，则发布afterrender事件
   6. 初始化事件，调用AbstractComponenet.initEvents()。initEvent()包含若干在组件渲染完毕后，需要初始化的事件监听器
      1. 如果具有afterRenderEvents，则把这些监听器注册为组件子元素的受管监听器，这些事件属于DOM事件
      2. 为当前组件添加焦点监听器（addFocusListener）
   7. 如果配置为隐藏，那么调用getEl().hide()
8. render()启用布局系统，转调AbstractComponent.resumeLayouts()静态函数
   1. 刷出布局，调用flushLayouts()
   2. 覆写pendingLayouts的runComplete方法防止死循环
   3. 调用pendingLayouts（类型Ext.layout.Context）的run()方法
      1. 调用Context.flushInvalidates()
         1. 转调Context.invalidate()，使相关的组件、容器布局失效
      2. 调用Context.flush()
      3. 调用Context.runComplete()

Renderable类包含以下成员：

Ext.util.Renderable的代码分析如下：