DOM事件标准定义了两种事件流，这两种事件流有着显著的不同并且可能对你的应用有着相当大的影响。这两种事件流分别是捕获和冒泡。和许多Web技术一样，在它们成为标准之前，Netscape和微软各自不同地实现了它们。Netscape选择实现了捕获事件流，微软则实现了冒泡事件流。幸运的是，W3C决定组合使用这两种方法,并且大多数新浏览器都遵循这两种事件流方式。

默认情况下，事件使用冒泡事件流，不使用捕获事件流。然而，在Firefox和Safari里，你可以显式的指定使用捕获事件流，方法是在注册事件时传入useCapture参数，将这个参数设为true。下面用个例子分别来测试这两种事件流。

1、冒泡事件流
当事件在某一DOM元素被触发时，例如用户在客户名字节点上点击鼠标，事件将跟随着该节点继承自的各个父节点冒泡穿过整个的DOM节点层次，直到它遇到依附有该事件类型处理器的节点，此时，该事件是onclick事件。在冒泡过程中的任何时候都可以终止事件的冒泡，在遵从W3C标准的浏览器里可以通过调用事件对象上的stopPropagation()方法，在Internet Explorer里可以通过设置事件对象的cancelBubble属性为true。如果不停止事件的传播，事件将一直通过DOM冒泡直至到达文档根。

测试的HTML文件，其中用到了mootools-release-1.11.js，对mootools的代码进行了改动：
     
给addListener方法里增加了setCapture参数，用于测试捕获事件流。

效果：

js:


测试结果ie和ff下效果一致：单击item2,会依次触发fn2、fn1、fn;单击item1,会依次触发fn1、fn;单击Container,只会触发fn;当在任何一个事件处理器里调用e.stopPropagation();都会阻止事件的冒泡。

2、捕获事件流
事件的处理将从DOM层次的根开始，而不是从触发事件的目标元素开始，事件被从目标元素的所有祖先元素依次往下传递。在这个过程中，事件会被从文档根到事件目标元素之间各个继承派生的元素所捕获，如果事件监听器在被注册时设置了useCapture属性为true,那么它们可以被分派给这期间的任何元素以对事件做出处理；否则，事件会被接着传递给派生元素路径上的下一元素，直至目标元素。事件到达目标元素后，它会接着通过DOM节点再进行冒泡。

这里ie与ff存在着很大的差异，甚至ie6与ie7的表现也各不相同，所以分开测试。

a、ff
事件从从DOM层次的根开始往下传递时，会被useCapture属性为true的事件监听器所捕获，而到达目标元素再从目标元素冒泡时，则会被useCapture属性为false的事件监听器所捕获。当在任何一个事件处理器里调用e.stopPropagation();都会阻止事件的传播。

b、ie6
用事实说话：

第一种情况：

单击浏览器的任何位置，都只是触发fn；

第二种情况：

单击浏览器的任何位置，会依次触发fn1、fn;

第三种情况：

单击浏览器的任何位置，会依次触发fn2、fn1、fn;

结论：如果HTML元素捕获了通过该元素的setCapture()方法对这个元素的设置，依附于该元素的处理器将会被事件触发，即使setCapture()方法
被调用的这个元素不在目标元素的祖先路径中。事实上你甚至单击浏览器的非页面部分都会触发事件处理器。并且事件一旦被捕获就不会继续再
往下传播（即使该元素在目标元素的祖先路径中），而是立刻冒泡。e.stopPropagation();会阻止事件的冒泡。
 
c、ie7
测试效果与冒泡事件流一致。将对捕获事件流的支持干掉了？
 
结论：正如mootools所做的，避免捕获事件流。


工作流现在已经应用的非常广泛了，审批OA等等自然不必多说，许多业务系统里也有大量的应用。前两天的
一个项目就是使用工作流将整个项目管理的过程进行整合，包括了前期预算、项目进度管理、合同管理等等。
可供选择的工作流也很多，商业的、开源的。那么你是如何评价一个工作流产品的好坏的呢？你的标准是什么？
当然，用户也经常会问我这个问题，我的回答是：根据你实际的业务。是的，不管是什么样的工作流，都是
为了满足业务的需要，你把你的需求提出来，我们看看是否满足，不能直接满足，最合适的间接方式又是什么。你说，我要有催办。是的，我们有。你说，我要有任意回退和任意流。是的，我们有。你说，我想对流程实例进行分级管理。oh,没有也，重要吗？让我们想想其他办法。你说，你们符合BPEL标准吗？这个。。。你说，你们采用了petri网模型吗？汗。。。你说，你们是SOA架构吗？。。。
我的衡量标准是这样的：
1、流转功能
  包括了基本的工作流模式实现，串行、并发、分支、汇聚、循环等等。这个是最基本的。其实打开流程设计器拖拖拽拽很快就能知道这个产品到底实现了哪些流转模型。实际这个的实现也是引擎的核心。有多种模型可以选择。petri 模型应该是最灵活的了，也有很大的实现难度。但是流程模型做这么灵活，到底实际能用上多少……就我个人的经验来说，大部分的复杂性都是由流程的分支并发（m/n）引起的，最坏的办法是强制要求客户将这些并发的任务改成 step by step 的执行。这样牺牲一点效率，还是可以把项目做成的。
2、业务的内在支持
  比如说催办、时间服务、收回等等。我觉得这个与实际业务挂钩，反而是最为主要的考虑。因为采用间接的方式必然会产生编程，而很显然会耗费成本。
3、与业务的契合方式
  流程维护流转。业务还是自己实现。如何将这两者很好的衔接起来。同时这个过程还存在权限的限定，每个运行节点对业务的权限肯定存在差别，是否有一套完整的解决方案？当然这其中也包括了组织机构的适配，对各种组织模型的支持。
4、定义良好的API
  通常会存在工作流无法直接满足的业务场景，那么肯定需要程序直接调用工作流的API，清晰且简洁的API。
5、流程的仿真
  这种仿真比较简单，目的在于检验所定义的流程是否正确。出错要有明确的提示信息。普元的单点调试？
6、电子表单
  我始终觉得电子表单目前实际应用并不理想，它仅仅只能处理简单的业务。但是销售的经验告诉我，这是一个巨大的闪光点。用户喜欢自己动手。流程定义实际最终用户很难实际操作。我在想：简化版本的流程设计器+电子表单也许会有很好的售前效果。
7、良好的售后
8、良好的最终用户体验
9、性能
10、最好能够和标准扯上关系，可是谁知道我是否真的有关系呢？
这是一个完全基于js的应用程序，区别于一般的web应用，它是oaop。大概需要一些什么样的工作呢？

大概的概念：

1、容器
 是的，需要容器。容器的两个目的：布局和管理组件。组件之间的相互通信以及影响都需要容器来协调。管理组件之间的状态，组件需要向容器进行注册。对组件传播过来的事件，容器需要做出处理，调用相关其他组件的方法或者忽略或者继续向上一级容器传播。

2、组件
 组件的目的是完全屏蔽对dom编程的依赖，同时屏蔽底层的浏览器事件，例如鼠标单击、双击等等，对这些事件进行完全的封装。组件有着自己的生命周期：初始化、渲染、重画、销毁等等。由组件完成页面的渲染工作，例如节点、画板、连线等等。

3、模型
 在页面进行建模是必要的，例如活动节点、流程等等，这些模型与组件衔接，它们之间的状态互相影响，比如节点组件名称的改变实际影响的是所对于节点模型的属性。画板节点的增加实际也会给响应的流程定义模型新增一个活动节点。

4、与服务器交互
 与服务器的交互完全基于xml。流程定义模型有着自己的xml方法，由xml解析为模型，由模型解析为xml，双向的过程。本地存储。很自然的选择。
 
可能的难点：
最大的难点就是组件的实现，事件的处理以及传播机制。

开发的过程：

1、底层库的选择
 面向对象的开发方式，底层库需要完成的工作：继承、接口实现、事件的统一处理接口、element DOM编程的封装。

2、基本组件的开发
 画板、图形组件、连线组件、弹出面板、简单表格组件、树等等。封装基本的事件。可以定制事件。

3、容器的开发，管理组件
 组件实际也是容器的实现，比如画板的概念。画板中节点之间的互相影响。

4、加入模型的支持

5、xml与模型之间的js解析

参考：
ext是一个不错的参考，但是太笨重，功能越多越缓慢，轻量实现。主要参考其中容器以及组件的概念。
draw2d 实现太简单，基本就是一个图形库，考虑其中对图形组件的实现。

内容

序
致谢
关于作者

第1章 AJAX和富互联网应用

    转变中的Web
       传统Web应用的痛处
       AJAX止痛药
    企业中的AJAX
    采用AJAX的驱动因素
       可用性
       网络利用率
       以数据为中心
       递增的技巧、工具和技术升级
       服务器不可知论
    关于应用
       AJAX技术
       编程模式
    AJAX的替换技术
       XUL
       XAML
       Java Applets 和Web Start
       Adobe Flash，Flex和Apollo
       OpenLaszlo
    小结
    资源

第2章 AJAX组成技术(AJAX Building block)

    JavaScript
       JavaScript类型
       闭包
       面向对象的JavaScript
       Prototype属性
       面向对象编程(OOP)和继承(Inheritance)
       易变性(Mutability)
       线程(Threading)
       错误处理(Error Handling)
       命名空间(Namespacing)
    文档对象模型(Document Object Model)
       基本原理
       操作DOM
    层叠样式表
       继承和层叠(Inheritance and the Cascade)
       内联样式
       样式表
       动态样式
    事件
       事件流
       事件绑定
       跨浏览器事件
       事件对象
    客户端通信(Client-Side Messageing)
       XMLHttpRequest基础
       处理数据
    小结
    资源

第3章 Web浏览器中的AJAX

        增量的AJAX
        对服务器影响
    HTML标准
       文档类型定义(Document Type Definitions)
       盒子模型
    启动加载AJAX组件
       onload事件
       浏览器编码技巧
    模型-视图-控制器
       视图
       控制器
       模型
    AJAX MVC
       AJAX模型
       AJAX视图
       AJAX控制器
       面向方面的JavaScript
    小结
    资源

第4章 AJAX组件

    命令式组件
    声明式组件
       服务器端声明式编程
       声明式Google地图
       替代方法

    自定义声明式组件
       行为式组件
       声明式组件
       关于声明
    构建组件
       基本功能
       连接到服务器
       最终版本
    小结
    资源

第5章 从设计到部署

    设计
        为AJAX建模
        应用模型-视图-控制器模式
        优先考虑性能问题
    设计原型
       线框绘制
       验证设计决议
    测试
       测试驱动开发
       调试
    部署
       JavaScript压缩
       图片合并
       保护知识产权
       文档
    小结
    资源

第6章 AJAX架构

    多层架构：从单层到多层
    异步消息
    轮询
    服务器推送
       Comet
    跟踪请求
    缓存：处理数据
    基本缓存
    在组件中缓存
    在浏览器中缓存
    在服务器中缓存
    在数据库中缓存
       MySQL
       MS SQL Server
       Oracle
    更新服务器端模型：并发
       悲观锁定
       只读锁定
       乐观锁定
       冲突鉴定
       冲突解决
       自动化的冲突解决
    流量控制(Throttling)
       客户端
       服务端
    可伸缩性
       负载平衡和群集
       AJAX可伸缩性问题
    离线AJAX
    Firefox离线存储
    Internet Explorer userData离线存储
    使用Flash客户端存储
    离线AJAX和并发
    小结
    资源

第7章 Web服务和安全性

    Web服务
    Web服务协议
       表象状态传输
       XML远程过程调用
       Web服务
       选择合适的工具
    客户端的SOAP
       IBM Web服务JavaScript库
       Firefox
       Internet Explorer
    跨域Web服务
       服务器代理
       URL片段标识符
       Flash跨域XML
       脚本注入
    安全性
    AJAX的安全性考虑
    跨域漏洞
       跨站脚本
       跨站伪造请求
       JavaScipt劫持
   SQL注入
       预处理语句
       存储过程
       XPath注入
    数据加密和隐私
    防火墙
    小结
    资源

第8章 AJAX可用性

    常见问题
       后退按钮和书签
       页面大小
       自动提交
    可访问性
       识别用户的可访问性需求
       JavaScript和Web可访问性
       屏幕阅读器和可访问性
       兼容JAWS的AJAX交互
       键盘可访问性
    可用性测试
    迅速而又随性的测试
       招募参与者
       设计和运行测试
    软件断言测试
       用于测试可用性的工具
       对软件辅助测试的一般忠告
    小结
    资源

第9章 用户界面模式

    显示模式
       动画模式
    交互模式
       基本交互模式
    小结
    资源
       拖拽资源
       进度栏资源
       活动指示器资源
       颜色淡出资源
       即时编辑资源
       向下钻取资源
       即时搜索资源
       即时表单资源

第10章 风险和最佳实践

      
       风险来源
          技术风险
          文化和政治风险
          市场风险
       技术风险
          范围
          浏览器能力
          可维护性
          向前兼容
          第三工具支持和代码过时
       文化和政治风险
          终端用户的期待
          可培训性
          合法性
       市场风险
          搜索引擎的可访问性
          范围
          货币化
       风险评估和最佳实践
          采用特定的AJAX框架或者组件
          渐进增强和不唐突的JavaScript
          Google 网站地图
          可视化的提示
          避免镀金式设计
          采用一种收益模型
          把培训作为应用的一部分
       小结
       资源
          搜索引擎优化
          统计
          网站地图
          屏幕截取工具

第11章 案例研究

    基于Web2.0 重新武装美国国防部
       背景
       挑战
       解决方案
       采用技术
       成果
    Agrium公司整合AJAX技术到业务
       背景
       挑战
       解决方案
       采用技术
       成果
    AJAX助力国际运输和物流公司
       背景
       挑战
       解决方案
       采用技术
       成果
    小结
    资源

附录A OpenAjax Hub

    主要特性：发布/注册管理器
       范例
       未来对OpernAjax Hub支持的工具包

索引

时间真快，一晃08年都过了半个月。一直很忙，也不知道在忙些什么东西。领导催着要份年终总结，于是就有了这个东西。还是分成两个部分：工作和生活。

工作：
1、年初的时候继续业务平台的开发，主要是修改BUG和书写使用文档，公司开始增加测试的岗位，平台也开始有订单，于是BUG像雨后春笋般的茁壮成长出来。实际一直到现在，那份长长的BUG单依旧存在，改不完的BUG。现在有很深的体会：一个好的产品，并不在于采用了多么先进的技术，重要的是要成熟，要贴近业务，而这需要的是时间和大量的项目经验。所以，要是想节约成本采购一个业务平台，首先需要考虑的是这个平台存在几年了？都被哪些实际项目采用过？它面对的业务是什么，是否符合我项目大部分的需求？对于号称采用很多新技术和通用性非常强且刚开发出来的所谓平台一定要慎用，很可能你就成了实验品。

2、业务平台的价值。其实业务平台是有很大的存在价值的。这个价值就是业务。我们公司产品的口号是：释放你的技术，专注你的业务。我认为这个口号相当不妥，正确的应该是：发挥你的技术，我们替你思考业务。业务平台还有生存的意义，至于意义单一的所谓开发平台，我看还是洗洗睡吧。

3、5月份开始进入工作流的开发，一直到现在。对工作流有了很多新的认识。工作流应该算是公司最核心的产品了。代码很臃肿，没有测试，但是分层还是非常的清晰。期间开始增加测试并增加功能，对引擎部分做了部分的重构。中间也陆续做过工作流的售前和售后工作。工作流，感觉是越来越普及了。但是感觉市场却没有想象的那么好，单独的工作流引擎有没有前景？其实可以这样分析：很多行业都有他们自己针对的行业软件公司，这些公司都有自己的业务平台和流程组件，虽然不是独立对外卖的；另外就是中小型企业和客户采用开源的工作流引擎了，这样积累的使用经验可以成为公司的财富，只要把核心人员留住，就不用每个项目都去购买一个商业工作流了，节约成本；可不可以这么认为：商业工作流的市场本来就很小呢？

4、12月到新疆出了趟差，然后就是全力开发新疆的项目了。这是一个大集中的项目，也就是一套系统，所有分公司一起使用，最 紧迫的问题就是组织结构、权限以及数据（包括流程）的分级管理了。现在是业务需求基本都满足，但是可以想象未来性能的压力，工作还会有很多。

个人技术：
1、上半年看过一些敏捷和UML的书籍。敏捷感觉已经是一个被用滥的词语，人人头上都顶着一个敏捷的帽子，就像言必称 spring"hibernate一样，有些恶心了。看过这些书，其实体会最深的还是如何开发出一个大家都能读懂的代码，如何与他人交流，能让别人看懂的代码就是好代码。至于UML，好像也能画上和看懂几个了。

2、最后一个季度和朋友一起翻译了《Enterprise AJAX》这本书，重新对ajax有了兴趣，翻译确实是一件辛苦的事情，但是现在回忆起来却很是觉得有意义。最直接的就是翻译水平有了很大长进，然后就是ajax有了一些新的认识。现在看Ext的代码，想着能否有扩展为类swing框架的可能性。期间参与了满江红组织的seam翻译工作，自己做的工作很少，纯属充数，算是了解了一把seam。

3、我和老婆说，怎么今年就感觉进步没有去年那么明显呢？老婆说，因为你去年起点太低！于是释然。

生活：
1、年初买了房子了，注明一下：是在老婆强烈要求下买的。地点在燕郊。
2、关注了厦门PX、上海磁悬浮，除去工作，开始关注很多东西，也开始看历史。

08的展望：
1、结婚
2、开发一个基于js的工作流设计器，能否完成？
3、做了3年的开发工作了，工作上能否有新的挑战？
4、多看点非技术书，多出去转转，善待自己和亲人。