安装Amfphp 1.9 beta 2

目前amfphp1.9的最新版是amfphp1.9 beta2，可以到 http://www.5etdemi.com/uploads/amfphp-1.9.beta.20070126.zip下载。将其解压缩到硬盘，拷贝到apache的web目录下。键入http://localhost:8080/amfphp/gateway.php，会出现amfphp网关的一个说明文件。AMFPHP基本的安装已经完成。

四、安装AMF扩展

最新版的AMFPHP加入了一个AMF扩展：它是用C写了一个AMF协议的解码和编码器，执行效率大大提升。尤其是大的数据源的时候，用php编码可能会超时而不能完成的操作，用AMF扩展就可以完成。 安装比较简易：

1. 下载

到http://www.teslacore.it/projects/amfext/amfext-0.8.7a-bin.zip下载，将php_amf.dll解压缩到PHP根路径下\ext中。

2. 配置

打开php.ini，加上下面这一行：extension=php_amf.dll

我们不需要对AMFPHP 本身做任何修改或者配置。系统会自动监测那个扩展是否存在，存在就会自动应用，否则就会使用PHP的解码和编码。

好了，将其web共享，别名为flashservices。支持Amfphp的Web应用就配置好了。我们只需要将写好远程服务类放到Amfphp根目录\services中就可以在Flash和Flex中访问了。

五、本地化设置

因为PHP默认的编码语言是ISO-8859-1，要使前面配置的Web应用支持简体中文，最好的方法是打开Amfphp根路径下的gateway.php，将 $gateway->setCharsetHandler("utf8_decode", "ISO-8859-1", "ISO-8859-1");修改为$gateway->setCharsetHandler("iconv", "GBK", "GBK");即可。要解决MySQL中的中文乱码问题，请用mysql_query("set names 'gbk'");。

/**//*
Remoting类
负责FLASH与数据库交互
*/
package {
    import flash.net.Responder;
    import flash.net.NetConnection;

    public class Remoting extends NetConnection {
        /**//*
        构造
        @param gatewayURL remoting网关地址
        @param amfType 使用AMF3或AMF0
        */
        public function Remoting(gatewayURL:String,amfType:uint) {
            super();
            this.objectEncoding=amfType;
            this.connect(gatewayURL);
        }
        //##########################################################################
        //
        //方法
        //
        //##########################################################################
        /**//*
         * 远程返回函数
         * @param remoteMethod:远程类.方法名param远程方法所需要的参数onResultFun:返回数据所调用的方法句柄.onFaultFun同理.
         * 
        */
        public function respond(remoteMethod:String,onResultFun:*,onFaultFun:*,... param):void {
            var parameters:Array=param;
            if (param.length > 0) {
                parameters.unshift(remoteMethod,new Responder(onResultFun,onFaultFun));
                this.call.apply(this,parameters);
            } else {
                this.call(remoteMethod,new Responder(onResultFun,onFaultFun));
            }
        }
    }
}

然后在任何地方可以调用它：

var remote:Remoting;
remote=new Remoting("http://localhost/remotinggame/gateway.aspx",0);
remote.respond(remoting方法名,onRuslt,onFault,参数1，参数2....);

function onRuslt(re:*):void{
       trace(" onRuslt:"+re);
}
        
function onFault(fe:*):void{
      trace(" onFault:"+fe.code);            
}

package {
    import flash.display.Sprite;
    
    
    public class Hello extends Sprite{
        
        private var remoting:Remoting;
        
        public function Hello (){
                init();
            }
        
        private function init():void{
                remoting=new Remoting("http://localhost:8080/amfphp/gateway.php",3);
                remoting.respond("Hello.sayHello",onGetData_Ruslt,onGetData_Fault);
          }
        
        private function onGetData_Ruslt(re:*):void{
                trace(re);
           }
        private function onGetData_Fault(fe:*):void{
            for(var what in fe){
                trace(what+"  fe:"+fe[what]);
            }
        }
    }
}

Rich Internet Application (RIA) 超出了 HTML 提供的传统用户界面 (UI) 控件的标准有限集合，比如文本框、复选框或单选按钮。RIA 为用户提供了丰富得多的控件集合，以及一种更加高级的服务器交互机制。使用 RIA，当从浏览器提交数据时，用户不必刷新页面；他们可以仅刷新页面的一部分，具有更好的错误处理，等等。

本文内容包括：

• RIA 概述
• UI 技术，包括 Laszlo、XUL、XForms、Dojo 和 Macromedia Flex
• 工具比较
• 其他技术

  RIA 概述

  术语 “Rich Internet Application” 已经出现几年了，但该概念还被称为：

  • 远程脚本
  • X Internet
  • 富 (Web) 客户机
  • 富 Web 应用程序

   

  Internet 是信息的巨大来源，许多技术在努力以高级和用户友好的方式改进 Web 上的信息传递和存储性能。在大多数 Web 应用程序中，大量处理发生在服务器端，只有用户交互发生在客户机端。从而使服务器承担了沉重的数据和处理负载，以及网络通信中不断增加的依赖性。

  传统的基于客户机-服务器的架构具有高的灵活性和丰富性，但随着 Web 的成长而日渐消亡。一个原因是缺乏客户机应用程序的一致性和标准化。现在，勿庸置疑，浏览器是已经被人们普遍接受的 Web 工具。但是，它缺乏智能处理。所以责任在于可以交付更丰富的用户体验并能在客户端进行简单处理的客户机应用程序。RIA 提供了设计更好、更快、更吸引人并更无限可用的用户体验的机会 —— 全部在浏览器中实现。

  致力于 Web 和 internet UI 层的开发人员通常在 UI 层上进行试验，尝试可以在最少外部支持下有效工作的各种 RIA 工具。但是，在多数情况下，浏览器需要一些支持以使插件、扩展或下载在浏览器内部无缝工作。

  本文讨论有助于为业务案例确定最佳 RIA 选择的工具和参数。本文不可能讨论 RIA 的所有因素，但我将重点介绍您在评估 RIA 技术时审核的一些重要特性。

  评估内容

  评估 RIA 技术时，需要考虑下列因素：

  UI 丰富性

  开发 UI 时有多少基本的、开箱即用的 UI 小部件或控件可以使用？可以如何使用这些控件进行数据绑定和事件绑定？新控件应易于使用，并易于插卸。一些 RIA 技术提供了添加丰富性的简单方法和信息更丰富的可视体验，比如页面中的动画 API。例如，为了确保用户仅点击某个按钮一次，可以将此按钮做成动画以从视图中移出。

  复杂性

  开发人员已经使用现有的基于页面的模型很多年了，因为它简单易用，但是可能很笨重。RIA 技术必须易于使用、构建和扩展。它还应该与现有 Web 技术相互操作。

  灵活性和组件化

  与不同中间件组件协作的灵活性非常重要。协作应该能够容易地组合和扩展，以创建新的自定义小部件。创建自定义小部件之后，就可以在应用程序中重用它们。

  刷新页面

  刷新页面的一块而不是整个页面有非常显著的好处，因为它直接依赖于网络流量。刷新一块使得应用程序更快、更可用并使用户具有更好的视觉体验。它还有助于更好地管理错误。

  假设用户在网页上执行一个操作或第一个任务，并且数据在后台提交给服务器。然后用户在同一页面上继续执行另一个任务。同时，来自第一个任务的反馈已经返回并更新同一页面的某个部分。因此，如果这样设计网页，则会使工作和任务更有效率。

  安全性

  采用 RIA 时，确保与传统应用程序相比不会增加安全性威胁。一定要清楚围绕服务器通信或下载在客户机上的浏览器插件和扩展的安全性。

  对基本 Web 范例的支持

  技术应支持当今 Web 应用程序中涉及的基本 Web 范例，比如国际化、用户设备独立、浏览器独立和对上载和下载功能的二进制文件传输支持。甚至技术的成熟度也很重要。

  工具

  检查以集成开发环境 (IDE) 形式可供开发人员使用的工具，以及单元测试和调试支持。工具可以是带有现有编辑器或受支持编辑器的插件。

  可用性

  用户期望浏览器应用程序使用常用的浏览器功能。具体来说，保存图片、Ctrl+F 以搜索页面上的内容以及复制粘贴等功能不能在基于 Flash 的解决方案中工作。以人机交互 (HCI) 原理设计您的 RIA 可用性。

  
  
  

  UI 技术

  本节讨论当前 UI 技术提供的一些不同选项。

  Laszlo

  Laszlo 是领先的开放源码平台，用于在 Web 中使用 Flash 来开发和交付 RIA。Flash 播放器最初具有一个小插件以在浏览器中运行 Flash 文件。因为其高可靠性和兼容性，它被扩展用于创建闪烁的动画图片。后来的版本合并了一些重要的脚本兼容性、与服务器的数据交换，Flash 6 添加了双向音频和视频通信。

  Laszlo 已经扩展了该丰富性，使用脚本语言来生成 Flash 并交付给浏览器。它提供了一个用于构建 RIA 的开发源码 XML 本地平台。

  什么是 XPath？ XML Path Language 是 W3C 推荐的语言，设计用于寻址 XML 文档中的信息。XPath 的主要目的在于导航 XML 文档中的任何节点和属性。

  它只需要在任何浏览器上安装 Flash 5.x+。脚本以一种叫做 LZX 的基于 XML 的语言编写。LZX 是一种面向对象的基于标记的语言，使用 XML 和 JavaScript 语法创建动态生成的 Flash 文件。服务器上的 LZX 编译器编译 LZX 文件并将 Flash 发送到浏览器中。实际的数据交换是以 XML 形式进行的，LZX 控件使用 XPath 来表示 XML。事件也很容易与控件绑定。每个控件定义一组可以从父事件继承事件的事件。清单 1 中的示例展示了如何使用事件。

  
  清单 1. 示例 simplelaszlo.lzx
  

  <canvas width="500" height="80"> <view> <text align="center" valign="middle">Hello, World!</text> <button >Update <method event="onclick"> Debug.write("Button pressed"); </met> </button> </view> </canvas>

  
  

  您将发现 Laszlo 易于学习、开发新组件、组件化并与任何 Web 应用程序集成。与其他 RIA 工具相比，它具有丰富的组件库。

  LZX 能够让 HTTP 和 Web 服务使用 SOAP 和 RPC 协议在后台请求服务器，而无需刷新页面。插件已经就绪，可以将任何 Web 应用程序文件与 Laszlo 库集成。当前，基于 Eclipse 的 IDE 可供开发使用。还有一些工具可用于在客户端的 LZX 中进行调试。有趣的是，它们还提供了 Lzunit 框架以用于测试 Laszlo 应用程序。

  最近，Laszlo 宣布了支持使用相同的现有框架将应用程序以 DHTML 交付给浏览器。这使您可以选择配置时希望将应用程序交付为 DHTML 还是 Flash。Laszlo 还扩展了对 Ajax 社区和多个设备交付的支持。

  图 1 展示了 Laszlo 和 Dojo 的示例。

  
  图 1. 用 Laszlo 和 Dojo 创建的 RIA 图片
  
  

  XUL

  XML 用户界面语言 (XUL) 是 Mozilla 的基于 XML 的跨平台语言，用于描述应用程序的用户界面。它提供了可用于页面中的现成组件库。目前，它仅应用于基于 Gecko 的浏览器中，比如 Mozilla Firefox 或 Netscape 6 以上版本。

  XUL 使用基于 XML 的标记语言描述用户界面控件。它提供了各种流行的富 Internet 控件，比如菜单、选项卡、树和弹出菜单。XUL 使用文档对象模型 (DOM) 存储节点树。加载了所有 XUL 文件之后，XUL 将所有标记解析并转换为层次文档结构的节点。然后可以使用此 DOM 结构、DOM 结构的方法以及 XUL 函数提供的其他方法来检查并修改数据。您始终可以从 JavaScript 访问并操作 DOM，并使之像典型的 HTML 控件一样易于处理。每个控件和每个节点都具有多个属性来定义其外观和结构。

  从远程位置访问时，浏览器像处理 HTML 或其他浏览器内容一样处理 XUL 文件。但是，当它们作为扩展而本地安装在其 chrome 系统的浏览器中时，条目将收到访问系统和书签的特殊权限。在这种情况下，它可以执行其他的特权操作。

  Mozilla 浏览器本身也是一组软件包，其中包括 XUL 文件、JavaScript 和样式表，但它是相当大的而且非常复杂的扩展。

  XUL 使用 eXtensible Bindings Language (XBL) 进行绑定。每个控件可以使用 Mozilla 的 XBL 被绑定。XUL 使用 RDF 格式，可用于存储资源。可以使用其他格式的数据，并从中创建 RDF 数据，该数据将绑定到 XUL 格式。

  因为 XUL 类似于 XML 文件，所以可以使用 IDE 的任何文本编辑器或 XML 编辑器。因为相同的底层代码处理所有 XUL 文件、HTML 和 SVG，所以可以使用 CSS 属性设置 XUL 文件的样式。它对定位具有内置支持，因为所有文本内容在浏览器中是保持分离的。

  皮肤 在 Mozilla 中由 CSS 文件组成，定义浏览器的用户界面。可以为不同的外观修改和创建皮肤，而无需更改代码。它类似于通过添加功能来扩展浏览器 API 的功能。

  如果在 Mozilla Firefox 中运行 清单 2 中的文件，它将呈现一个文本框和按钮。

  
  清单 2. 示例 simplexul.xul
  

  <?xml version="1.0"?> <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <window id="example-window" title="Example 2.4.1" xmlns:html="http://www.w3.org/1999/xhtml" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <label control="label" value="Enter some text"/> <textbox id="textid"/> <button id="yes" label="Yes"/> </window>

  
  

  XForms

  XForms 1.0 提供了一种新的用于联机交互的平台独立标记语言。W3C 已经出现了用于实现 XForms 的规范，而且 XForm 被认为是 HTML 形式的继任者。

  XForms 独立于表示设备。无需对传统浏览器、PDA 移动电话、语言浏览器、甚至一些更奇怪的新兴客户机（比如 instant messenger）进行任何更改，就可以传递 XForms。这使得 XForms 成为更吸引 RIA 的工具。

  在 XForms 中，实际数据（XML 表单定义）与表单表示分离。这种设备独立的 XML 表单定义叫做 XForms 模型，可以用于许多标准的或专用的用户界面。

  XForms 用户界面提供了一组标准的可视控件，旨在于替换当今的 XHTML 表单控件。它们可用于 XHTML SVG 或其他组、语言浏览器组中，还可以独立开发 XForms 的用户界面组件。XForms 模型被引用在每个 XForms 控件中以呈现数据。它遵循 XPath 以引用 XML 中的元素。提交数据时，它只能提交已填充的 XML 数据模型。

  XML 事件 XML 事件 是一种 XML 语言，能够一致地将事件监听器和关联的事件处理程序与 DOM 事件集成。当事件发生时，它被通过文档树路径分配给元素（目标），并可以再次传递回树中。观察者可以响应路径中的事件。

  XForms 使用 XML 事件来处理事件和动作。XML 事件指定事件、观察者和处理程序。正如 清单 3 所示，DOMActivate 是事件，消息元素是处理程序，父触发器是观察者。

  可以将 XForms 与 AJAX 集成。当前，在 W3C 中，可以找到 20 多个 XForms 示例实现。许多供应商，其中包括 IBM，已经开发了 XML 的 XForms 引擎（参阅 参考资料 中的 XML Forms Package）。Mozilla 已经宣布在 Mozilla 运行的所有平台上支持 XForms。要查看 XForms 实现的优秀示例，请参阅 参考资料。

  清单 3 展示了一个简单的 XForms 示例，显示了一个用 FormFaces™ 实现呈现的文本框和按钮。

  
  清单 3. 显示用 FormFaces 实现呈现的文本框和按钮的 XForm
  

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:form=http://www.w3.org/2002/xforms xmlns:ev="http://www.w3.org/2001/xml-events" xml:lang="en"> <head> <title>Simple example</title> <link rel="stylesheet" type="text/css" href="xforms.css" /> <script type="text/javascript" src="../../formfaces.js"></script> <form:model> <form:instance> <data xmlns=""> <greeting>Hi there!</greeting> </data> </form:instance> </form:model> </head> <body> <form:input ref="greeting" incremental="true"> <form:label>Greeting:</form:label> </form:input> <form:trigger> <form:label>Trigger</form:label> <form:message level="modal" ev:event="DOMActivate">You clicked button</form:message> </form:trigger> </body> </html>

  
  

  Dojo

  Dojo 是用 JavaScrip 编写的开放源码 DHTML 工具包。Dojo Toolkit 提供了一组核心库，和一组丰富的不同的软件包库，每个库提供特定的函数。Dojo 提供较低级的 API 来编写可移植的 JavaScript 并简化复杂的脚本。可以很容易很快地原型化交互小部件和动画转换。它提供了事件系统、I/O 软件包和一般语言增强的库。可以用 Dojo 编写脚本，并根据您的需要包括任意多个可用的 API。

  Dojo 还提供了一组可直接用于任何应用程序中的小部件库。可以使用其中一些核心小部件作为 UI 控件，比如菜单小部件、选项卡集、树小部件等等。还有一般函数，比如布局小部件、日期选择器、SVG 小部件等等。

  Dojo 基于单个标记语言构建，提供了声明和使用响应 DHTML 界面组件的简单方法。清单 4 展示了一个简单的 Dojo 组件示例，它是 HTML 页面中一个面向用户的特殊按钮。

  
  清单 4. 示例 dojosample.html
  

  <button dojoType="Button2" widgetId="helloButton">Hello World!</button> You need to include the Dojo widgets library that is required in your HTML page. <script type="text/javascript"> dojo.require("dojo.widget.*"); dojo.require("dojo.widget.Button2"); </script>

  
  

  Dojo 工具包还包括一些调试选项。AJAX Toolkit Framework (ATF) 可用作功能强大的 IDE。这是 IBM 的 Emerging technology Toolkit (ETTK) 的一部分，是一组特殊的新兴技术。ATF 主要基于 Eclipse Web 工具项目，允许支持 DOM 浏览、JavaScript 调试等等。

  最近，Dojo Foundation 宣布了与 Laszlo 的合作协议。按照该协议，您可以在 Laszlo 的开放源码项目中使用 Dojo Toolkit。同样，Laszlo 将将库贡献给 Dojo Foundation，从而促进开放源码社区的发展。

  Macromedia Flex

  Macromedia Flex 是另一种基于 Flash 的用户界面。它提供位于应用服务器顶层的 Flex 表示服务器，并从该服务器动态生成 Flash 文件，然后交付给浏览器。这些 Flash 文件在浏览器的 Flash 播放器内部执行，并允许用户交互、执行操作、甚至生成 SOAP、HTTP 或 AMF 请求以连接回服务器。

  布局和 UI 组件在一种基于 XML 的语言 MXML 中定义。Flex 为可视组件、容器以及远程服务对象和数据模型提供了丰富的 MXML 扩展类。它还与控件进行数据绑定，并访问服务器端数据。

  ECMA 脚本语言 (ActionScript 2) 嵌入在 MXML 中以处理事件、系统事件或构造复杂的数据模型。这是一种面向对象的语言，类似于 JavaScript 和 ECME 脚本。与 XForms 一样，Flex 保持数据模型、数据表示、数据验证器和数据服务分离（类似于 MVC 样式）。

  到达 MXML 的所有请求都通过 Flex 编译器进行处理，该编译器编译 MXML 并生成 SWF，然后将其高速缓存，直到它被修改并最终交付给浏览器为止。

  任何 XML 编辑器都可用于编写 MXML 脚本，但 Macromedia 还提供了一个特殊的 IDE 进行 Flex 应用程序开发，叫做 Flex Builder 1.5。它的优点是与 Flex 服务器集成。它还提供了一些组件，允许连接服务器、执行正常的 HTTP 调用、连接远程 Java™ 对象并从浏览器本身与 Web 服务交互。它可以与现有的 J2EE 和 .NET 应用程序模型集成。

  清单 5 展示了 Macromedia Flex 代码的一个示例。

  
  清单 5. Macromedia Flex 代码示例
  

  <?xml version="1.0"?> <mx:Application xmlns:mx="http://macromedia.com/2003/mxml"> <mx:Form label="Employee Information"> <mx:FormItem label="First Name"> <mx:TextInput id="firstName" /> </mx:FormItem> </mx:FormItem> </mx:Form> <!-- The myEmployee data model. --> <mx:Model id="myEmployee"> <name> <first /> <last /> </name> <department /> <email /> </mx:Model> mx:Binding source="firstName.text" destination="myEmployee.name.first" /> </mx:Application>

  
  

  Macromedia Flex 看起来类似于 Laszlo。二者都是丰富的功能强大的基于 Flash 的应用程序。Laszlo 位于 Flash 引擎外，所以性能可能有所欠缺，但它具有其他优点。

  
  
  

  工具比较

  下表比较了上文讨论过的五种技术以及 Altiolive（一种丰富的企业应用程序）。

  
  表 1. 工具比较
  

  技术	浏览器技术	脚本	丰富性	亮点
  Laszlo	Flash、XML	LZX 文件+JavaScript	高	易于学习，丰富
  Mozilla XUL	XUL 语言	XUL 文件+JavaScript	高	依赖浏览器，功能强大
  XForms	Xform	取决于实现	限于一定程度	设备中立，遵循 W3C
  Dojo	JavaScript	HTML+JavaScript	限于一定程度	基于 JavaScript。正在成长，可适应。
  Macromedia Flex	Flash、XML	MXML 文件	高	非开放源码。Macromedia 的专有工具。
  Altiolive	Applet、XML	Java	限于一定程度	http://www.altio.com/

  
  
  
  

  其他技术

  我们已经讨论了五种技术，当然还有其他一些技术。许多公司使用各种技术提供了非常特别的 RIA 原型。尽管一一讨论这些技术超出了本文范围，但下面这些技术值得一看：

  • Backbase —— 开发和销售帮助创建 AJAX 应用程序的软件。
  • Netvibes —— 自定义 Web 主页解决方案的免费服务。
  • Zimbra —— 下一代企业消息传送和协作的开放源码服务器和客户机技术。
  • Protopage —— 免费个人起始页面。
  • Nexaweb —— 用于绑定和部署 Enterprise Internet Application 的平台。
  • altio —— 浏览器中丰富的企业应用程序。
    
    

  结束语

  本文介绍了 RIA，讨论了当前的 UI 技术，并推荐了其他技术。我希望工具比较将帮助您根据需要作出一个正确的选择。每种技术都有不同的优点，从而基于您的需要为开发人员提供了丰富的控件集合。

  本文讨论的技术为用户带来一些新奇的东西，并提供了更丰富的用户体验。您现在可以跨越浏览器并呈现给 PDA、跨平台的移动设备，并用音频、视频、图像和动画来丰富用户体验。RIA 几乎包含了 XML，因此 XML 无疑是优胜者。

  将来，我预计 RIA 将会在 Web UI 转换到下一级别中扮演重要的角色，并帮助准备支持 Web 2.0。

　　引入了 package（包） 和 namespace（命名空间） 两个概念。其中 package 用来管理类定义，防止命名冲突，而 namespace 则用来控制程序属性方法的访问。

　　新增内置类型 int (32比特整数)，uint（非负32比特整数）,用来提速整数运算；

　　新增 * 类型标识，用来标识类型不确定的变量，通常在运行时变量类型无法确定时使用。在 AS2 中这种情况下需要用 Object 赖作为类型表识；

　　新增 is 和 as 两个运算符来进行类型检查。其中 is 代替 AS2 中的 instanceof 来查询类实例的继承关系，而 as 则是用来进行不抛错误的类型转换。

　　新增 in 运算符来查询某实例的属性或其prototype中是否存在指定名称的属性。

　　新增 for each 语句来循环操作 Array 及 Object实例。

　　新增 const 语句来声明常量。

　　新增 Bound Method 概念。当一个对象的方法被付值给另外一个函数变量时，此函数变量指向的是一个 Bound Method，以保证对象方法的作用域仍然维持在声明此方法的对象上。这相当于 AS2 中的 mx.util.Delegate 类，在 AS3 中这个功能完全内置在语言中，不需要额外写代码。

　　AS3 的方法声明中允许为参数指定默认值（实现可选参数）。

　　AS3 中方法如果声明返回值，则必须明确返回。

　　AS2 中表示方法没有返回值的 Void 标识，在 AS3 中变更为 void。

　　OOP方面的增强

　　通过类定义而生成的实例，在 AS3 中是属于 Sealed 类型，即其属性和方法无法在运行时修改。这部分属性在 AS2 中是通过类的 prototype 对象来存储，而在 AS3 中则通过被称为 Trait 的概念对象存储管理，无法通过程序控制。这种处理方式一方面减少了通过 prototype 继承链查找属性方法所耗费的时间（所有父类的实现方法和属性都会被直接复制到对应的子类的 Trait 中），另一方面也减少了内存占用量，因为不用动态的给每一个实例创建 hashtable 来存储变量。如果仍然希望使用 AS2 中类实例在运行时的动态特性，可以将类声明为 dynamic。

　　API方面的增强

　　新增 Display API，使 AS3 可以控制包括 Shape, Image, TextField, Sprite, MovieClip, Video, SimpleButton, Loader在内的大部分 DisplayList 渲染单位。这其中 Sprite 类可以简单理解为没有时间轴的 MovieClip，适合用来作为组件等不需要时间轴功能的子类的基础。而新版的 MovieClip 也比 AS2 多了对于 Scene（场景）和 Label（桢标签）的程序控制。另外，渲染单位的创建和销毁通过联合 new 操作符以及 addChild/removeChild 等方法实现，类似 attachMovie 的旧方法已被舍弃，同时以后也无须去处理深度值。

　　新增 DOM Event API，所有 在DisplayList 上的渲染单位都支持全新的三段式事件播放机制，以 Stage 为起点自上而下的播报事件到 target 对象（此过程称为 Capture Phase），然后播报事件给 target 对象（此过程称为 Target Phase），最后在自下而上的播报事件（此过程称为 Bubbling Phase）。

　　新增内置的 Regular Expressions （正则表达式）支持，使 AS3 能够高效地创建、比较和修改字符串，以及迅速地分析大量文本和数据以搜索、移除和替换文本模式。

　　新增 ECMAScript for XML (E4X) 支持。 E4X 是 AS3 中内置的 XML 处理语法。在 AS3 中 XML 成为内置类型，而之前的 AS2 版本 XML 的处理 api 转移到 flash.xml.* 包中，以保持向下兼容。

　　新增 Socket 类，允许读取和写入二进制数据，使通过 AS 来解析底层网络协议（比如 POP3, SMTP, IMAP, NNTP 等）成为可能，使 Flash Player 可以连接邮件服务器和新闻组。

虽然在很多方面，Silverlight表现出了比Flash更佳的性能，例如与AJAX结合更紧密，更容易动态生成，对搜索引擎更友好，开发工具集成度更高，等等。本文作者还是从以下四个方面列举了Silverlight无法取代Flash的理由。

技术潜力

对于一个专业开发者，在考虑选择哪门技术的时候，很重要的一个方面就是这门技术的发展潜力。包括它的改善空间、提升余地，以及你投入时间掌握这门技术后获得的经济回报。

在短时间内，Silverlight会表现出强大的潜力。微软是一家资本雄厚的大公司，典型的微软模式就是，微软会为Silverlight砸很多钱，让人们相信这是一门值得学习的技术。我知道有许多Flash开发者已经通过开发Silverlight项目赚取了可观的收入，这些项目是由Redmond直接或间接援助的。Adobe在这个方面完全不能和微软竞争。虽然Adobe也有雄厚的资金，但还远比不上微软那样富到可以买上一个小国家。

从长远来看，人们从Silverlight开发中学到的基本知识也不会昙花一现。但是，如果你真的对开发跨平台交互式WEB感兴趣，Silverlight技术未来将会在很大程度上把你的成功锁定在同一个平台（Windows）上。

小结：Flash也许没有如Silverlight淘金般的发展潜力，但它是一门非常确立和成熟的技术（98%的安装基础，其中85%以上是Flash Player 9版本），它还会继续扩大它的使用范围，并在相当长的时间内在开发交互式Web领域稳定增长。当前微软在推动Silverlight发展方面投入了大量的金钱，但是在未来如果微软不再象现在这样往里面砸钱的话，Silverlight的前景就另人担忧了。

运行时

大多数对这两门技术的讨论都集中在其虚拟机的性能上。很正常，一个平台的成功性在很大程度上决定于它的性能。对于Silverlight，我并不是了解太多，但从现有资料看来，当前1.0beta VM基本上是SVG/WM接口。它并不支持构件（AKA controls），没有现成的语言解释器，也没有太多另人兴奋的亮点。而在新发布的α版Silverlight 1.1中这些方面有了明显的改进。但是Adobe在这方面还是处于领先地位，成熟的跨平台开发体验，对目标市场也有更深入的理解。

接口大小和实用性也是考察的重要因素。Flash player，包括两个虚拟机、大量的功能程序，只有2MB，功能残缺不全的Silverlight1.0 beta是1.2MB（Mac上是5.3MB）。支持动态语言运行的α版Silverlight 1.1扩大到4.2MB（Mac上是10.3MB），如果要浏览Managed SilverLight的网页,就得下载这个Runtime,这对于储存空间拮据的手机系统来说,还是稍嫌庞大些。我预计将来还会更加庞大。接口大小在几年前也许还不是什么大问题，但它仍然会对接受度有很大的影响。在另一个方面说来，与网络相连的电脑上已经有98%都安装了Flash player了，它能自动更新，可以在Windows、Mac和Lunix上运行，是发布后升级最迅速的软件产品（前提是用户接受新版本）。

小结：如果微软在这些方面继续改进，Silverlight会有非常大的潜力。不幸的是，我看到他们动作缓慢。Adobe仍大规模的领先，在实用性和普及率方面。

开发工具

我看过Expression suite，它给我留下了深刻印象，微软对它做了很大的改善。他们从Adobe的成功中学习长处并改进了其缺点。微软有许多开发实用开发工具的经验，这在它们的Expression工具中就可以看出。在这方面，Adobe并没有太多创建开发工具的经验。微软正在对Expression进行更新。Adobe也在做着一件深远的事，就是集成他们的开发工具创建一个凝聚性的工作流。

从另一个角度，微软并没有开发设计工具的经验，事实上他们对设计者还不够了解。他们的工具只能在Windows平台上使用，这从一开始就切断了一半的设计者市场。在今年的微软MIX大会上，一位参会者在会间询问Lynda（Lynda.com站长），如果设计者们熟悉Expression后将如何转到Windows平台上去。她回答说她自己就是个Mac用户，但她不会转到Windows上去。我为Lynda的诚实鼓掌，我相信这也清楚的证实了微软要想让抵制者们改变原来的工具并不是一件容易的事。

小结：微软将会建立更完善的开发工具集，并提供更佳的集成工具。但是，他们事实上是不愿意支持Macs的，他们并不能深入的理解创造性和设计者是他们的要害。Adobe对创造的流程有很深入的理解，它们对跨平台的支持性是微软不能比敌的。

未来趋势

虽然很容易被忽视，但这是一个非常重要的问题。为什么微软会构造Silverlight？微软的长远意图是什么？现在主要猜测是用来抢占Flash的RIA应用市场，但根据过去的观察，微软的行动一直很稳健，我想这一次也不会例外。

微软因为其经常会在一项技术已被事实证明是成功后，再进入这个领域而臭名昭著，他们会扔进大量的金钱逐渐去扼杀竞争，一旦形成垄断，技术的发展就会遇到很大的阻碍。微软也经常会因一时的怪念头而放弃对跨平台特性的支持。确实，他们提供的很多跨平台产品到最后都会因为某种冠冕堂皇的理由被抛弃或半途而废（MAPI in Entourage, IE, VBScript in Office, Windows Media versioning and DRM, heck, 甚至Halo）。

Adobe也不是慈善家，但他们已经证明自己的产品能够成功的支持跨平台特性，即使在交互式WEB页面开发上真正意义上的竞争者并不多，但Adobe一直在对产品进行改进。Silverlight会迫使他们做的更好。举个例子，如果没有Silverlight的出现，我们能否如此快的在Linux上看到Flash player9也将会是个疑问。

小结：如果消灭掉了Flash，继续追求跨平台特性就不会是微软最佳利益的选择了，也很难保证持续对其革新。做为一个长期的Mac用户，我真的不能相信微软的意图，但是看到在Silverlight的压力下Adobe的持续改进也是一件另人高兴的事。

结论：总的说来，我相信Silverlight的潜力，尤其在短期内微软砸进大量金钱的效果会比较明显。在不远的将来，微软的开发工具也可能会更加健壮，比起Adobe提供的工具有更高的集成度，但是仅仅支持Windows平台的特性会让大量的开发者和设计者与Silverlight保持距离。我相信Silverlight接口将会是一个合适的运行时程序，但它不会象Flash player那样打包到用字节计算，也决不会达到象Flash那样的安装普及率。