我的理解之Flex Event

Flex Event 就是Flex框架的消息机制。
        对于一个Application，也可以看做是多个组件集合的结果。在这样的构架中，我们可能会希望各个元素之间既能互通消息，又能保持相对松散的结构。这时就可以采取消息机制：需要某个操作，就发送消息，监听结果，而非等待。得到消息的组件再做处理，返回结果。这样的机制也非常适合网络环境，如果网络条件不好，不能及时作出相应时，异步处理的消息机制就能避免因等待而产生的系统消耗。

         事件驱动，消息机制：可能就是从C/S到B/S开发时，最核心的思维变化了。

        Flex框架定义了对象以及其消息传递的方法。从事件被触发到事件的处理完成，会经历三个阶段：捕获阶段、目标匹配阶段、冒泡阶段。每个阶段，节点都有机会对事件作出反应。
         对于可视对象（Display Object），比如一个按钮。当点击按钮以后，Flex会搜索哪些对象对事件注册了监听器。它的搜索顺序是从根祖先Stage开始，SystemManager、Application、Panel、TitleWindow、直到找到事件的发出者Button，即捕获阶段。抓住Button后，触发其监听器，执行事件处理函数，即目标匹配阶段。最后层层回溯向根节点，这一过程称为冒泡。 在消息传递的过程中，消息所到之处，如果有监听器，则其对应的处理函数都有可能被执行。若要控制只在捕获阶段触发或冒泡阶段触发，可以设置use_capture或bubbles属性。 * 特别注意鼠标和键盘事件的处理，都处于冒泡阶段，其捕获过程是默认无效的。
        对于非可视对象，如http的请求，它没有捕获阶段，直接被目标节点调度，也没有冒泡阶段。

    依照Flex这样的消息机制，ArcGIS API for Flex也封装了一些组件及消息。仍然是两类：一是可见的控件类，如map、layer等，二是不可见的task处理。我们在开发时，可针对不同类型的消息传播的特点，进行监听、响应设计。

    而对于Flex Viewer框架，除了使用了API的那些封装好的消息外，也基于EventDispatcher类扩展了一个消息类EventBus，从中我们也可以学习到如何扩展事件控制的方法。这个消息发送器的主体是ViewerContainer。任何类，主要获取到ViewerContainer这个对象，就能向EventBus这个消息通道里发信息。由于ViewerContainer对于这个Application来说，又是一个全局的容器，因此各种消息可以在这里共享、发散。另外，EventBus传递的消息类，也做了扩展，即AppEvent。它也是继承与Event，只不过还添加了一个data属性，这样在消息传递过程中，还可以加入了我们的自定义数据。非常方便。