写作本文的目的是为了能让自己对基础的概念更加熟悉，尽管近期都在关注Flex领域，不过得承认，HTML和JavaScript方面的能力很重要，并不是所有的开发者都认同我的说辞：“复杂的业务我倾向用Flex实现。”——rosen jiang

什么是DOM？

从我参加工作开始嘴上就老是挂着DOM，起先认为DOM只是针对XML领域，后来才知道HTML也是一种DOM结构。W3C多DOM的解释是：文档对象模型(DOM)是一种平台、语言无关的接口，允许程序和脚本动态访问和更新其内容、结构和样式。处理后的文档可以再次处理，并且处理的结果可以重新呈现在页面上。

什么是文档(Ducument)？

文档就是一段合法的XML串或一段HTML，在概念上文档应该有根以便能访问到里面的数据。

DOM的级别

DOM Level 1，DOM Level 1第一版又分成DOM Level 1 Core和DOM Level 1 HTML。

DOM Level 1 Core定义了一组最基本的访问和操作文档的对象和接口，是一种满足所有软件开发者和web脚本开发者访问和操作HTML、XML的功能性规范。

DOM Level 1 HTML继承了DOM Level 1 Core，主要描述HTML文档方面的对象和方法。一般来说，DOM Level 1 HTML要能实现维护结构化的文档、元素和属性。

DOM Level 2，DOM Level 2又分成DOM Level 2 Core、DOM Level 2 Views、DOM Level 2 Events、DOM Level 2 Style、DOM Level 2 Traversal and Range Specification、DOM Level 2 HTML。在这里我只关注Core和HTML。

    DOM Level 2 Core和Level 1的定义一样，并基于Level 1构建。

DOM Level 2 HTML基于DOM Level 2 Core构建，且不与DOM Level 1 HTML兼容，DOM Level 2 HTML也是目前HTML 4.01和XHTML 1.0所采用的级别。

DOM Level 3，在这里就不多描述了，目前还没有DOM Level 3 HTML规范，我看DOM Level 3 Core的描述还是针对HTML 4.01的，难道是在等传说中的HTML 5？对于HTML 5的相互争论是可以的，奉劝各大浏览器厂商不要把头打破了。

HTML DOM对象包括所有的标签，例如<a>就是一个DOM对象，HTML中的<a>标签（元素）实际上是实现了DOM Level 2 HTML的HTMLAnchorElement接口，再比如<div>标签（分组元素）实现了HTMLDivElement接口。既然DOM Level 2 HTML和HTML 4.01关系紧密，那么可以存在：document.createElement(“div”)来创建DIV对象。可参考HTML 4.01规范来找寻其支持的元素。对于span这样的分组元素在DOM Level 2 HTML中是实现了HTMLElement接口，与span一样实现HTMLElement接口的元素是：

• 特殊: SUB, SUP, SPAN, BDO
• 字体: TT, I, B, U, S, STRIKE, BIG, SMALL
• 表达: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ACRONYM, ABBR
• 列表: DD, DT
• NOFRAMES, NOSCRIPT
• ADDRESS, CENTER

这里面最特殊的DOM对象是document，它实现了HTMLDocument接口且没有对应的HTML标签，HTMLDocument是整个HTML层次的根并能处理HTML的所有内容。

除了内置与HTML对应的对象外，HTML DOM（浏览器）中还内置了JavaScript对象，他们是：Window、Navigator、Screen、History、Location，可阅读HTML DOM 参考手册，里面解释得很清楚。需要说明的是：Window 对象表示一个浏览器窗口或一个框架。在客户端 JavaScript 中，Window 对象是全局对象，所有的表达式都在当前的环境中计算。也就是说，要引用当前窗口根本不需要特殊的语法，可以把那个窗口的属性作为全局变量来使用。例如，可以只写 document，而不必写 window.document，还有用得最多的alert()方法，也不用写Window.alert()。

总结完毕。

请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处： http://www.blogjava.net/rosen

最近一直在使用 Flex3 对原有项目进行重构和 bug 修改。遇到不少性能问题，分析发现由于 Flex 在和 Servlet 交互时使用了大量的 XML 作为传输格式，导致某些功能在处理 XML 时非常的慢，甚至还 Error #1502: A script has executed for longer than 15 seconds。让人痛不欲生！

和 RIA Meeting 组织者 lwz7512 交流后，他建议使用 BlazeDS 来代替 XML 操作。随着对 BlazeDS 的渐渐了解，的确能解决不少性能问题。Adobe 的 Flex 技术传道士 James Ward 在 BlazeBench: Why you want AMF and BlazeDS一文中详细比较了利用 BlazeDS 所带来的性能提升，下图是 James Ward 写的性能测试工具。

通过上面的测试数据发现，正如 BlazeDS 官方网站所提到的：在使用 AMF3 作为传输协议后，Flex 和后台交互的性能大约提高了10倍。面对这一结果，想必大家很兴奋，看来是时候用 BlazeDS 来替换 XML 了。不过问题并不是这么容易就解决了，由于 BlazeDS 在 2007年12月12日才正式开源发布，而在这之前项目都是以 XML 作为传输格式（当然也没用GraniteDS），并且 Flex 代码中处处可见对 XML 的操作，要对这样的代码进行重构......难。

要解决 XML 处理的性能问题。就应该好好的利用 E4X，尽量避免在解析 XML 的过程中使用循环。这里介绍几篇文章让大家了解下《E4X：出色的 JavaScript》、《E4X 教程》、《AS3中新的XML处理方法 – E4X》。E4X给我最大的便利就是..运算符。思考下面的XML：

要得到所有属性fullname是”rosenjiang”的person节点的个数怎么做？在没详细了解 E4X 之前，我会用 myXML.group 操作得到 group 的 XMLList 集合，然后再用循环去找寻每个 group 中 person 节点属性 fullname 为”rosenjiang”的数据：

上面的写法的确很傻，下面是改进之后的代码，关键部分只有一行：

通过合理使用 E4X 语法，顺利的避免了循环带来的性能问题。过了几天，来个新的需求，需要统计出在这个 XML 中有几个不同姓名的 person。思考片刻，我可不可以用眼睛数出来啊？这里有 3 个...... 好吧，看来又是循环问题，第一个想到的是用两个嵌套 for 循环来进行排除处理，这是最直观的想法......

下面我介绍下如何用 ArrayCollection 并只使用一个循环来计算个数。由于 Flex 里面不支持 Map 类型，而我 Google 了一圈，且 RIACN 论坛上网友的 Map 实现性能都不行，遂打算用 ArrayCollection 模拟 Map 进行操作：

上面代码没什么过多解释，思路是取出一个 fullname 放进 ArrayCollection，然后判定下一个 fullname 是否存在于 ArrayCollection 中，如果存在就跳过，不存在就放进去再取下一个。另外我发现，使用 for each 比单纯的使用 for 性能要高一点点。

做了以上的努力后，性能还是低下！怎么办？看来没什么办法了，和你的 boss 谈谈吧，考虑下进行大刀阔斧重构的可能性。或者能否在超时后给用户一个提示，让他操作的数据量少点，需要做的是捕获超时异常，既 ScriptTimeoutError，请参阅http://www.cs.vu.nl/~eliens/pim/assets/flex3/langref/flash/errors/ScriptTimeoutError.html，进行 try catch 。 Good luck！

Flex简介
       Macromedia公司被公认为新兴的RIA市场的领导者。今天98%的浏览器上都使用Macromedia Flash客户端软件，因此几乎每个人都可以使用基于Flash的RIA。Macromedia Flex是Macromedia的新服务器产品，它使企业应用程序开发人员能够全面访问RIA的功能。Flex具有基于标准的架构，与当前企业开发人员的工具、方法和设计模式互补。

    Flex应用程序与传统的HTML应用程序的主要区别在于Flex应用程序处理最适合在客户端运行，如字段校验、数据格式、分类、过滤、工具提示、合成视频、行为及效果等。Flex 可使开发人员更好地交付应用程序，这种应用程序使用户可以迅速反应、在不同状态与显示间流畅过渡，并提供毫无中断的连续的工作流。

                                             Flex 应用程序框架

  如上图所示，Flex应用程序框架由MXML、ActionScript 2.0及Flex类库构成。开发人员利用 MXML及ActionScript 2.0编写Flex应用程序。利用MXML定义应用程序用户界面元素，利用ActionScript 2.0定义客户逻辑与程序控制。Flex类库中包括Flex组件、管理器及行为等。利用基于Flex 组件的开发模型，开发人员可在程序中加入预建的组件、创建新组件或是将预建的组件加入复合组件中。

      这里重点介绍一下MXML。与HTML一样，都是标记语言，它描述了反映内容与功能的用户界面。与HTML不同的是，MXML 可对表示层逻辑与用户界面和服务器端数据绑定提供声明抽象。MXML可将表示与业务逻辑的问题彻底分开，以实现最大程度地提高开发人员的生产率及应用程序的重复使用率。

    Flex的不足
      目前Macromedia最新推出了Flex 1.0 Updater，但它代号为“Brady”的IDE还没有正式推出，目前还在进行Beta 3测试。抛开IDE不说，笔者认为Flex目前还很不成熟，还不利于在实际项目中使用。

    例如，Flex自带的ZipCodeValidator，里面只提供了美国和加拿大的邮编规则，没有其他选择，也无法个性化它。看来只有自己来定义Validator了，但这样一来，和在JS中写正则表达式有什么区别（代码量和JS差不多）？用户需要的是国际化的ZipCodeValidator，这样才能提高工作效率。

    一句话概括
      现在的Flex才是1.0版本，很多地方都不完善，只好自定义才能完成特定的要求。期待着Brady以及Flex后续版本的推出！

RIA方案—基于JS的Bindows

Bindows简介
    “Bindows把JavaScript发挥到了第九层！”——网友这样评价Bindows。

                             运行中的Bindows

    的确如此，Erik等编写这个框架已经将JavaScript的OOP和基于IE6的DHTML发挥到极点！Bindows 0.93发布的时候已经将IE内置的功能开发得淋漓尽致了，包括Filter、XMLHTTP、Web Service、VML。JavaScript用于客户端界面的显示和处理，XMLHTTP用于客户端与服务器的信息传输。JavaScript在客户端的表现力不容置疑，看看www.bindows.net所表示出来的能力，利用JavaScript几乎可以实现Windows应用程序所能干的大部分事情，XMLHTTP一直以来常被用于实现“无刷新”的Web页面，它和JavaScript配合，可以完成数据从服务器和客户端的传输。
   
    Bindows的不足
    Erik喜欢那种一次全部载入的方式来实现脚本库，使用过Bindows会发现，在窗口的加载期，需要一个漫长的等待过程，甚至浏览器的进程会产生无响应的情况。按照V0.93，脚本文件的大小是600多K，在一个普通的Web应用中，我们更多时候不会用到Bindows的全部功能，这点Bindows根本没有遵循“用多少去多少”的准则。另外，过多的JS会使CPU占用率陡然增加，产生潜在问题。

    内部大量利用了IE6的技术，没有考虑到非微软平台的浏览器，限制了Bindows的流行。在图表方面，大量采用了VML技术，在IE5，IE5.5这两个版本，VML引擎不是那么的成熟，很多地方的显示不够流畅，会受到带宽和硬件的限制，过分绚丽的图形最终会给用户带来崩溃。“图形方面我是采用VML的，当初太偏执，如果使用SVG来实现可能好许多的，也就是那段日子，我花了非常多的时间去折腾web方面开发。”——有网友这样说。

  一句话概括
    在技术的角度上，从Bindows是可以学到不少东西的，但好像它的学术价值大于它的商业价值。

后 记

    兴奋归兴奋，冷静下来仔细想想，运用RIA改造现有B/S模式还为时尚早。制约我们的首先是网络环境和硬件环境的不完善性，我想没有哪个用户愿意花大量的时间来等待想要看见的“花哨”页面，更不愿意等来的东西使自己的机器不堪重负，而换来的只是一些良好体验吧？市场决定一切，而不是任何的新技术！其次，目前RIA的解决方案也不成熟，笔者看好Flex，可惜还需要长时间的等待才有结果。当然，还有很多RIA的方案，感觉MS的Smart Client + Web Service来头不小。

    本文叫“迎接RIA时代的来临”，笔者充满了对RIA的美好憧憬，期待着有一天能够在RIA的环境中进行虚拟现实的交互式体验！

鸣 谢：RIA中国 没有他们，我想今天也不会对RIA有如此的认识！！！


参考文献:

Flex 白皮书
IDC--RIA白皮书
回归C/S?解释Bindows
迎接Client/Server模式的回归
Flex: RIA 的先驱，无坚不摧的银弹？
Return of Rich Client


请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处：http://www.blogjava.net/rosen

    看了几篇关于“回归C/S”的文章，作为一名多年开发B/S的程序员，不免热血沸腾，深受鼓舞！曾经，我是B/S结构的忠实拥护者，同时也为了所谓的“零部署”陷入过技术泥潭。正当为B/S烦愁的时候，RIA走进了我的视线… …

什么是RIA

    Internet已经日益成为应用程序开发的默认平台。用户对应用程序复杂性要求日增，但现在的Web应用程序对完成复杂应用方面却始终跟不上步伐。用户与今天中等复杂程度的Web应用程序交互时，其体验并不能令人满意。Web模型是基于页面的模型，缺少客户端智能机制。而且，它几乎无法完成复杂的用户交互（如传统的C/S应用程序和桌面应用程序中的用户交互）。这样的技术使得Web应用程序难以使用，支持成本高，并且在很多方面无法发挥效应。

    为了提高用户体验，出现了一种新类型的Internet应用程序。那就是Rich Internet Applications（RIA）。这些应用程序结合了桌面应用程序的反应快、交互性强的优点与Web应用程序的传播范围广及容易传播的特性。RIA简化并改进了Web应用程序的用户交互。这样，用户开发的应用程序可以提供更丰富、更具有交互性和响应性的用户体验。

                           基于主机模式→C/S模式→B/S模式→RIA模式

   我们的行业经历了几次系统架构方面的重要转变，在此过程中，客户端的表现功能有起有落。上图介绍了每个阶段的计算功能所带来的应用程序体验方面的变化，这一过程从大型机开始，到RIA的出现为止。

   随着各企业组织认识到RIA模型可产生显著的商业利润、提高生产率及降低成本的优势后，这种模型的发展势头越来越猛烈。这些应用程序结合了桌面应用程序的反应快、交互性强的优点与Web应用程序的传播范围广及容易传播的特性。系统架构发展的下一步是RIA，它最大程度地提高了广泛性和丰富性。

论传统B/S之不足

    过程复杂性
    过程复杂性是由于需要表达一个多步骤或多选项任务或互动作用所引起的。在HTML里，一个多步骤的任务可以在单页内表达出来。但是由于HTML的互动性有限，便可能产生一份很长的页面，使用户感到混乱、笨拙而难以使用。为了避免这种难以忍受的用户体验，便需将任务在表面上看来“自然”的部分处区分成多个步骤，甚至需多个网页共同完成。这种以网页为主的用户界面通常需要反复翻转网页，以解决在顺序步骤中有牵连性的改变。其结果是缓慢、不自然、混乱而且令人感到懊恼的用户体验。
    
    配置复杂性
    许多Web应用程序允许用户配置自己所要的定制产品——可以是皮包或是计算机，甚至是汽车等产品。但是配置产品是一项很困难的过程，因为在向用户展示所有有效的产品选项组合时，应用程序必须能够表达出有关的复杂性，尤其是当用户可以从数十、数百或数千选项中定制出一个产品时。表达这些复杂性包括指出所需条件、有效和无效组合、一些导致问题的元素以及它们的适当解决方法；为每一项个人选择提供费用信息以及费用总计（一旦有所更改）；还有最重要的是容许用户观看最后结果。这些是传统Web应用程序相当难以表现的。

 规模复杂性
    今天，网站内的搜索工具大多是文本性质，间中夹着一些锦上添花的图像。当用户输入他或她的数码照相机准则，有可能是价格、以像素等，网站便接着回复数页符合准则的产品，而大部分都是说明文本。反之，另一种方法则是使用视觉化来简化搜索空间（也就是提供立即和动态的视觉反馈）。在一个视觉化选择照相机的网站，其搜索过程可能如下：网站从一个包含所有照相机种类图像的单屏幕开始。当用户通过复选框、游标或数据输入域来选择筛选准则时，所有不符合准则的照相机图像将被删除，只余下符合准则的照相机可在屏幕上看到。因此，在把选择聚焦至符合准则的数部照相机的过程中，用户可经历一个截然不同，而且和现实生活中的购物经验更相似的体验。

  反馈复杂性
     高度互动性的应用程序如游戏，能使反馈变得复杂，也即是指用户行动和快速移动或情节不断改变的屏幕元素之间的反馈环路。传统的HTML页面一向来都可以说是无法表达这类复杂性。它所需要的是拥有高度互动性和局部智能型的客户端应用程序，以便可以在无需刷新全页或干扰与服务器之间的通信的情况下，响应用户的输入和改变它们的状态或界面。放弃如今依赖服务器的客户机将使用户体验更吸引，同时也解决了反馈复杂性的问题。Web应用程序必须拥有表达复杂性的能力，以容许用户视看复杂的数据、配置多选项的产品、搜索大型数据集以及容许用户与数据之间的互动交换。

真正的RIA

    为了解决如今的问题，理想中的Web应用程序应该能够：
1、 利用无处不在的客户机
2、 在多种硬件平台上毫无更改的操作互联网
3、 无论低或高带宽的连接都可毫无妨碍的执行
4、 将处理能力复原给客户（而不仅是提供能力而已）
5、 提供吸引人的高度互动的用户界面
6、 表达过程、数据配置、规模和反馈复杂性
7、 无缝的利用声音、视像、图像和文本
8、 容许用户在线和离线工作以支持移动工作流程
9、 容许客户自行决定要在何时存取何种内容和数据（异步内容检索）
10、 存取多种中间层服务（.NET或Java）和后端数据存储
11、 采用新崛起的标准如XML和SOAP，为演进中的Web Service为主的网络提供动态高效的前端应用
12、 与遗旧的应用程序和系统集成
13、 容许在现有Web应用程序和环境内逐步添加新功能以充分利用现有网络应用投资

       

JavaScript 的任务是通过 DWR servlet 来调用指定的 Java 代码，动态创建 iframe。DWR servlet 的任务是配置一些参数，调用服务器端 Java 代码为调用者向 iframe 提供返回数据。

译者语

    DWR 是个新东东，目前仅仅被认为是 alpha 版。在这一领域，据我了解还有 XML HTTP Request object（一般称作XMLHttp） 和 XML-RPC。国内使用 XMLHttp 的很多，包括我前几个月所参与的项目，实现了很多以前认为 B/S 很难办到的需求，不过遇到的问题也不少，相同版本的 IE 有的却要报错，让人很恼火。XML-RPC 国内用户就少多了，我未接触过 XML-RPC，在此不作过多评价。

在这样一个日新月异的时代，希望 DWR 能经受住考验！



请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处：http://www.blogjava.net/rosen