由上可知,基于XML的用户界面标记语言,能够为用户应用程序的开发模式带来近乎革命性的变革,尤其是微软在MSDN网站上通告了自己的XAML(XML Application Markup Language)语言之后,更引起了大家对这项技术的广泛关注。
下文就针对目前最受关注的两种用户界面标记语言XUL(XML User Interface Language)和XAML进行一些介绍和对比,希望能够引起大家对这项技术的分析和讨论。
1.什么是XUL
XUL也许是历史最久远也最广为人知的XML-based GUI language,它由mozilla基金会创建,其目的是为了快速开发mozilla项目的界面工作,目前mozilla suit的界面都是由xul实现的,包括Mozilla browser suite,轻量级的浏览器Firebird,邮件客户端Thunderbird 以及Netscape browser suite。 Safari
同样实现了 一些XUL,另外还有一个项目(Luxor toolkit)使用XUL为 Java Swing定义用户接口,其他的xul实现可以参考XUL Alliance。
2.XUL 简述
2.1 XUL的结构
XUL是一种标记语言,用来定义用户界面元素的布局,而界面的外观(颜色,字体等等)可以通过属性以及CSS和图片定义。
元素的行为则通过脚本ECMAScript定义,也可以使用编译的从c++通过AOM(是W3C的DOM扩展)与元素交互。行为与XUL元素的绑定是通过XBL技术实现的,该技术是由mozilla发布的,并已经向W3C提交。因此通过CSS或者DOM,便可为特定的元素绑定外观和行为。
目前XUL还不支持SVG,XForms,SMIL以及其他的UI相关的W3C技术,当然,没有理由以后还不支持,实际上目前已经有项目正在使mozilla支持SVG(要注意的是,在XAML中,微软使用了自己的矢量图像语言WVG,并且和SVG并不兼容,同样,还有一个和SMIL很相像的动画语言)。
XUL语言的tags由下列四种元素组成:
(1)布局元素(比如hBox,vBox,grid以及stack等)
(2)构件widgets(比如menulist,menubar,toolbar以及button等)
(3)命令,加速键(比如command以及keyset)
(4)xul模板(为UI绑定后台数据,使用RDF)
在Mozilla中处理XUL文件的过程,与显示一个HTML页面的过程很相似(尽管没有surrounding Window chrome),首先是XML文件被解析,将XUL文件中的标签构建为一棵DOM(Document Object Model)树,在这个过程中,相关联的CSS将被用来定义标签的外观,在建立布局对象之后,便可以将结果显示给用户了,例如是一个对话框,或者是一个窗体。
究其本质,XUL的核心还是比较简单的,它的目的便是采用XML语言对对话框以及窗体上GUI元素及其布局进行描述。
因此,要想真正地使用XUL技术,便不可避免地需要下列技术的支持:CSS,DOM,RDF,XML,XBL,JS以及XPCOM。
2.2 XUL的装载
载入XUL文件可以大致分为五个步骤:
(1)XML文件被用来构建了一棵DOM树
(2)CSS被用来定义这棵DOM树的外观
(3)XBL通过CSS被附加,用来定义构件(widgets)的实现。有些构件采用C++定义,有的采用XBL/JS定义,还有一部分是两者的混合。XBL对于构件的实现是非常重要的(除非你要自己设计自定义的构件)。
(4)JS可以在XUL文件中对事件进行处理,许多服务都可以通过XPCOM封装被JS调用。这也正是mozilla工具包定义的核心所在,包括文件i/o,网络装载,拖拽功能(drag and drop)等等。
(5)RDF提供了为用户界面绑定后台数据的功能。可以把它当作一个信息(也许存储于数据库中)与用户界面的胶水层。
Mozilla还为XML文件和脚本提供了一种二进制的方式,从而避免了对XUL文件进行不必要的多次解析,CSS的风格定义是极为快速的(也就是说是高度优化的),而JS也是不错的,速度也很快,主要被用来绑定用户界面和后台的服务(也许是C++实现的)。
当然,使用XML+CSS的引擎也有问题,那就是用户希望GUI的窗体能够立即显示,与此对照的是,也许浏览器装载一个网页需要1到2秒的时间用户也可以忍受。所以从这一点上来说,采用这种用户界面技术的应用程序需要足够快的机器来运行,以弥补构建用户界面所需的额外花销。
还有一点要注意的是,与采用预定义的构件相比,使用用户自定义的构件并不会增加系统显示窗口的时间,因为构建XML,DOM,定义风格,以及布局等操作的消耗,都与是否采用了预定义的构件无关。
2.3 XUL的实现
要实现XUL,必须:
(1)建造一个XUL+CSS+DOM+JS的布局引擎
(2)实现附加的布局基元(layout primitives),比如spring,strut模型以及popups等,这些附加的布局基元可以和标准的CSS定义的布局基元进行互操作。
(3)实现一个二进制的cache,以便加速XML和JS的重载速度。
(4)实现一个组件/标签扩展模型,例如XBL,允许XML标签可以被定义为组件,并在其他的页面,窗口和对话框中复用。
(5)实现系统其他构件的XML标签支持,例如tree等等,这些构件在HTML中没有实现。
(6)通过某种数据绑定形式(Mozilla采用的是RDF),提供后台数据与GUI XML文件的绑定。
(7)除了本地语言格式之外,还要为JS提供一套完整的SDK,支持文件I/O,网络等操作。
(8)实现基础构造支持,提供命令运行和命令更新的支持
(9)为CSS和XML实现一种高效的内存缓存,以便实现轻量级的原型复制和共享(可以使用类似“写时拷贝”的语义)。
3.什么是XAML
微软将在2006年推出的Longhorn平台,包括多种技术更新,包括:
(1)与下一代sqlServer技术结合的文件存储系统WINFS
(2)新的表现子系统(Presentation subsystem)"Avalon"
(3)号称是下一代SOAP的新的通讯子系统"Indigo"等
而在其Avalon子系统中最大的技术亮点便是其推出的界面声明语言XAML(发音为'zammel'), 微软在十月份的PDC(Professional Developers Conference)上发布了该语言的声明,马上引起了广泛的关注,XML-based GUI languages在过去几年内发展很快,尤其是mozilla平台的XUL(发音‘zool’),被认为是界面声明语言的发展方向。而此次微软推出的XAML,和mozilla平台的xul有着很多相似之处,因此我们有必要对XAML进行一些了解和对比。
4.XAML 简述
微软的XAML是进入XML-GUI竞争的新成员,由于微软对自己产品技术的强力宣传,还是立即引起了众多的注意和评论。
由于微软的Longhorn要等到2006年才发布,因此XAML也许会在此期间发生比较大的改动。
XAML通过XML的语法,使用微软新的基于矢量的图形库(vector-based drawing library)Avalon。对于Mac程序员来说,Avalon和Apple的Quartz(基于PDF和OpenGL)很相像,而对于linux程序员来说,会觉得这种xml+vectors的组合来自KDE和GNOME的桌面环境。因此可以说,XAML并没有什么新的或者独特的技术。相对新的东西是,原始的XAML文件可以通过Longhorn版本的IE进行浏览,这一点和XUL可以通过mozilla浏览器浏览有几分相似。
XAML被用来创建画布(canvases,一个用来显示图像,文字以及widgets的区域)、widgets(比如一个button或者menu)以及shapes(比如圆,直线,贝塞尔曲线等)等的实体,这些元素最初始的外观通过他们的属性来定义(就像XUL和SVG一样),或者使用一个XAML特有的'style'元素(element)来定义。元素的行为可以使用任何.NET兼容的语言来定义(目前支持C#,VisualBasic.NET or JScript.NET),有两种方式可以将行为与界面元素绑定,一种是将行为的定义(代码)附加在XAML文件中的CDATA段落中,另外一种是通过一个和W3C的DOM类似的树状结构对widget进行访问。
下面的例子是一个XAML文件的内容,其中包含了C#的代码,可以看到代码都在<def:Code>标签中,并且由<CDATA[...]]>包围,这样解析器便可以在解析XAML文件时忽略该代码段。
<Canvas ID="root" xmlns="http://schemas.microsoft.com/2003/xaml"xmlns:def= "Definition"> <Button ID="button1" Click="Clicked">Click Me!</Button> <def:Code> <![CDATA void Clicked(object sender,ClickEventArgs args) {Button1.Content = "Hello World"; }]]> </def:Code></Canvas> |
用户还可以使用.NET兼容的语言定义自己的widgets,并在XAML中进行复用。当使用XAML预定义的元素时,比如菜单,按钮等,你可以通过两种方法进行预览,第一种是对其进行编译,并像其他windows程序一样运行;第二种方法是使用Longhorn版的IE进行装载预览。
如果你使用C#为widget定义行为,那么不论这个widget是自己创建的还是XAML预定义的,那么这个widget必须要进行编译。也就是说,如果你想在浏览器之外运行你的XAML widget,那么必须对XAML进行编译。
能否通过JScript.NET定义构件行为,从而可以在IE中运行不需编译的XAML widget,目前还不明确。同样的,XAML的widget能否嵌入web页面中,XAML中的元素能否通过ECMAScript 和 DOM编写脚本,以及能否通过CSS进行样式控制,目前都不明确。唯一明确的事情是:微软避开了所有W3C的建议,比如SMIL,SVG以及DOM,而为XAML实现了一些与上述建议相似但不兼容的技术。
在Windows程序之外XAML能否获得成功目前还很难说,Adobe目前为AfterEffects提供了生成XAML的插件,其他厂商是否会跟随,还需要时间的检验,但Steve Maine认为XAML将击败其他类似的技术,因为最终用户并不关心平台独立性。目前看来这种观点似乎是正确的,大多数用户并不关心应用程序能否在多种平台上运行,他们只关心程序能够在他们的平台上运行。MacOS,Linux以及其他的Unix系统,甚至包括老版本的windows,都不能运行基于XAML UIs的应用程序。根据以前Windows版本的更新情况来看,新版本要想被大多数用户使用,要经过一个很长的时间,在Longhorn发布之后,估计还需要大约3年的时间。因此,XAML要想成为WEB技术的扩展,还有很长的路要走。
5.XUL与XAML的对比
通过上面的描述,可以看到微软的XAML结构是比XUL大的多的,XUL的初始目的是为了构建Mozilla的用户界面以及面向web的应用程序,它并没有被设计为一个可以写出类似Adobe PhotoShop软件的语言,也就是说,从一开始,XUL面向的便是web领域,所以自然而然地便采用了一系列地web技术,比如CSS和JavaScript。Web开发人员由于对这些技术都比较熟悉,因此转向XUL技术是比较容易和平滑的。
而对于XAML,这种技术的转变仅仅影响.NET的开发人员,因为XAML所涉及的几乎都是.NET的技术,对于web开发人员,这种转变的面临着巨大的技术鸿沟,因此要想在web领域使用XAML技术,不可避免存在很多困难。
目前,XAML和XUL的讨论正在互联网上展开,并且这两种技术也都在发展的过程当中,因此要想对它们做一个比较完整的对比是比较困难的。下面仅列出当前状态下,这两种语言的一个简单对比,以供参考:
6.其他XML GUI项目 目前还有很多XML GUI的项目,例如XWT,Java GUI Builder,用于GTK+ 工具包的Glade(支持GNOME桌面环境),以及支持KDE桌面环境的XML GUI Builder,以及wxWindows的XRC等。