EXT 组建的生命周期

      这几天再看EXT的书《Ext JS in Action》。看到life cycle.但凡发现带cycle的字眼的技术的貌似都挺重要的。这里当笔记记录一下。

    这里有一幅图: 

     这幅图很好的显示了。ext的生命周期有三个状态:initialization,Render,destruction

   

    能够很好的利用Ext的框架，就必须需要要理解这个生命周期是如何工作的。如果你需要拓展一个组件和插件等等。这就尤为重要。

    首先看看Initialization

   

Initialization

    initialization时期就是组件出生的时候(直白翻译就是这样，原文是“The initialization phase is when the component is born”，怪别扭的)，所有配置的设定，事件的注册，和pre-render(真不知道如何翻译。就是将组件放到需要显示的地方)都是在这个时期完成的。如图

接下来是看看上图中的每一个步骤的详细信息：

    1.Configuration的应用(The configuration is applied):在实例化一个Component的一个实例的时候,需要传入一个包含所有所需要的参数和引用的配置对象(configuration object)让这个组件做指定的业务，当然这部分的的完成是在Ext.Component这个基类之前完成了

    2.组件事件的注册(Registration of the base Component events):每一个组件和每一个组件的子类，如果通过默认的方式，那么每一组事件都是从基类开始触发的。以下的一些方法是在被触发之前或者之后发生的:

    enable/disable, show, hide, render, destroy, state restore, state save。如果一个注册事件的处理能够成功返回before events 将会触发和测试，如果不能成功返回将会在action真正被调用的地方取消方法的调用。例如：在myPanel.show被调用的时候，他将会触发beforeshow事件，并且执行注册在该事件上的任何方法。如果beforeshow事件处理的结果返回的是false,那么myPanel将不会显示

    3.ComponentMgr registration(ComponentMgr registration):每一个Component的实例都会注册到ComponentMgr这个class中去，并且有一个ext 产生的唯一的字符串类型的Id(Ext-generated ID),你可以在configuration object中传递一个参数(id)重写这个Ext-generated ID。需要注意的是如果传递的Ext-generated ID已经存在，那么新的Ext-generated ID将会覆盖前一个。如果你想使用自定义的id要注意这个id的唯一性

    4.执行initComponent(initComponent is executed)：一个子孙类的initComponent这个方法里执行了很多工作。比如注册指定的事件，指定数据存储类型和子组件(child components)的创建。initComponent的使用是对组件结构的部署,因此在使用的一个关键所在就是要继承(extending)一个component或者是其他的Component的子类。我们在后面会详细介绍initComponent的继承(extending)

    5.Plugins are initialized:如果插件是通过传入到了配置对象(configuration object)中去构造的。那么他们的初始方法将会被调用，并且作为一个引用传递给父component。重要的是要记住，插件被调用的顺序与应用的顺序是一样的

    6.状态的初始化(State is initialized):If the component is state-aware, it will register its state with the global StateManager class. Many Ext widgets are state-aware

    7.Component is rendered:如果renderTo或者applyTo参数传入到了架构中去了，render阶段将会在这个时候开始，否则component将会处于dormant状态，并且等待着render方法被调用。

 

Render

    在这个时期，如果初始化成功了你将会得到该Component一个可视化的反馈(就是图形界面了)。如果初始化时期因为什么原因失败了，那么该Component可能就不能再该时期显示了。For complex components, this is where a lot of CPU cycles get eaten up, where the browser is required to paint the screen and computations take place to allow all of the items for the component to be properly laid out and sized

   

    如果renderTo 或者 applyTo 没有特别指明.那么render方法就必须被调用。在触发的时期，如果该组件不是其他ext component的子组件，那么必须必须调用render方法,传入一个Dom元素的应用：

   

someComponent.render(‘someDivId’);

    如果component是其他组件的子组件，那么他的render的方法将会在父component中被调用。以下是render期间的不同步骤

    1.beforerender is fired:component将会触发beforerender事件并且检测注册事件返回的结果。如果返回false,那么component将会暂停render方法。回想一下在初始化期间的两个步骤：注册核心事件，如果事件返回的结果为false,并且也能够在暂停执行方法。

    2.The container is set:每一个组建需要有一个存在的地方，这个“地方”就是所说的容器，实际上，如果某一组建的renderTo指定了一个引用的元素，那么该组建就会增加一个子div元素到引用的元素。这个元素被称之为container，并且添加一个child到该元素中。如果某个component指明了applayTo，那么这个applayTo的参数的引用就是该component的容器，component仅仅只会添加items到容器中去。在applayTo被引用的Dom元素将会被component管理。You generally pass neither when the component is a child of another component, in which the container is the parent component.只需要传入applayTo或者renderTo。

    3.onRender is executed：对于一个Component的子类，这是非常关键的，所有的Dom元素都会被显示到界面。当继承一个Ext.Component或者其他子类的时候。每一个子类首先都会去预调用父类的onRender.

    4.The component is “unhidden”:许多被render的component隐式的使用默认的Ext Css 类就像“x-hidden”. 如果autoShow被设定了，那么可以覆盖默认的的css类，使用自定义的Css。有一个非常重要的点：在这一个步骤中是不会触发show事件的。因为在这个事件上的监听器还没有被触发。

    5.自定义Css样式(Custom CSS classes or styles are applied):能够通过cls和style参数使用自定义css类和styles。如果设定了该参数，那么他们就会将这些css或者styles应用到组建的容器上去。这里建议用cls代替style，Css的继承规则能够被引用到组建的子组建中去。

    6.render事件的触发(The render event is fired):在这一个步骤，所有需要的元素都已经注入到DOM当中去了，而且styles也已经应用到当中去了。render事件将会被触发，同时触发注册在事件上的处理程序。

    7.afterRender is executed:afterRender事件是个非常关键的方法，他将会在Component基类的render方法之后被自动调用。可以通过它去设置Container的size或者执行其他的方法。所有Ext.Component的子类都会预先去调用Ext.Component的superclass.afterRender方法。

    8.The component is hidden and/or disabled:如果在配置对象configuration object中指明了属性hidden或者disabled其中的某一个为true的话，那么对应为true的hide或者disable方法将会被调用，并且都会触发对应的"before(Action)"事件，which both fire their respective “before<action>” event, which is cancelable(这里不能理解什么意思)。如果两个属性都是为true，并且“before(Action)”事件返回的不是false，这个Component将会隐藏和不可用。

    9.State-specific events are fired:如果Component的状态是state-aware，它将在它的Observable中初始化的state-specifid事件，并且注册this.saveEvent内部方法作为每一个状态事件的处理。

    10.一旦render时期完成了，他就准备开始和用户交互了，除非component隐藏了或者disabled。在调用destory方法之前，它会一直存在于内存中。

 

Destruction

    就像真实的生命一样，在生命当中，死亡是非常重要的时期，Component的Destruction是个关键的任务。例如：从DOM树结构中移除自己以及子元素。ComponentMgr的component注销，事件监听的注销如下图：

 

component的destory方法可以通过父容器调用，或者直接通过代码调用。这里是生命周期的最终时期。

    1.beforedestroy is fired：就像很多“befor<action>”事件。是个可以取消的事件,如果他的处理方法返回的是false，将可以防止component的注销

    2.beforeDestroy is called:这个方法在Component的destory之前调用。在这里做一些移除非组建的items是最佳的选择。例如toolbars或者是button.子类都会预先调用父类的beforeDestroy。

    3.Element and Element listeners purged:如果component已经被rendered,所有被注册到element的处理方法都会被移除，然后element将会从dom结构中被移除。

    4.onDestroy is called:Component类自己的onDestory方法并不会执行任何操作，但是子类可以预先使用这个去执行post-destruction(不知道什么)操作，例如移除数据。至于Container类。它会间接地管理所有在该Container内的子类。并调用其子类的onDestory的方法进行销毁。最终减轻开发者的任务负担

    5.Component is unregistered from ComponentMgr(在ComponentMgr没有注册的Component):该component的引用将会被ComponentMgr删除.

    6.The destroy event is fired:任何注册在事件上的处理方法被该事件触发了之后就表示当前的组建已近不在DOM中了。

    7.Component’s event handlers are purged(清除事件方法):所有事件处理方法的注销是通过component调用的。