一个值得关注的RIA项目(AJAX)

之前关于RIA的讨论中提到,JavaScript/Dhtml/XmlHttp(AJAX)技术速度快,负荷轻,易部署.但,目前AJAX最大的问题在于----缺乏一个好的界面工具库.----这使得目前用AJAX技术来构造界面就像用汇编语言书写GUI一样,笨拙而且低效.

技术比较可参见本人之拙Blog

不过这个情况目前似乎有了改变的迹象.

qooxdoo:http://qooxdoo.sourceforge.net/

qooxdoo(还不知道怎么发音)是一个纯JavaScript的UI组件库.它Host在SourceForge上,比较新,而且很活跃,就目前的Demo而言,令人印象非常深刻.

qooxdoo demo

将它的BuzzWord贴过来.没有时间翻译,大家凑合着看吧.有时间有兴趣的,check it out.

About

qooxdoo is an advanced open-source javascript based toolkit. qooxdoo continues where simple HTML is not enough anymore. This way qooxdoo can help you to get your rich web application interface done - easier than ever before.


Core Features

Client detection

Naturally qooxdoo comes with a client detection. Our one is really simple and currently only detects the engine of the client. Nothing more is currently needed for the other code. So we retained this part really “basic”.

Browser abstraction

qooxdoo includes an browser abstraction layer named QxDom, which tries to abstract all browser specific things to one common “standard”. The usage of QxDom simplifies the real coding of widgets and many other things. QxDom comes with some basic functions needed multiple times when creating real GUIs. For example you could get runtime styles or positions (in multiple relations: page, client and screen) of each element in your document.

Debugging

To easily extend and develop with qooxdoo we have included a debug console (QxDebug) which is able to display any debug message in relation to any instance of your application. Messages will be grouped by instances. This makes it easier to detect which object throws which debug message.

Event management

qooxdoo come with it’s own event interface (QxEventManager). This includes event registration and deregistration functions. Furthermore we have the possibility to call the target function in any object context. (The default is the object which get the event listener.)

Focus managment

Among the own event managment qooxdoo includes it’s own focus managment (QxFocusManager). This extends the includes browser focus handling and make any QxWidget instance you wish focusable. This is nice for accessibility and so on. The focused object receives all QxKeyEvents.

Timer

Similar to the common problem to handle DOM-Event to object mapping, it is somewhat problematic to handle intervals and execute a function in context to an object. To solve this problem qooxdoo comes with its own timer interface (QxTimer). Each timer instance could be configured with its own interval delay and then send out an QxEvent on each occurence.

Borders

Our border implementation (QxBorder) allows to hold a complete border setup in each instance. You could apply one QxBorder instance to multiple QxWidget instances. This dramatically simplifies the usage of borders in your web application. If you update any properties in your QxBorder instance each widget use this border get updated. qooxdoo come with some preset borders like groove, inset, rigde, ...

Properties

qooxdoo support “real” properties for objects. This means any class can define properties the created instances should have. The addProperty handler also adds getter and setter functions for this property. The only thing one need to add, if the property should do something (not needed on pure status properties), is to define a modifier function which really applies the new value. The property handling omit recursions, too: If property a change property b and property b change property a this will be stopped (to let this work you must use the uniqModIds functionality). This mechanism makes it really easy to let widgets or managers or any dependend object inform each other.


Interface Features

Widgets

Many properties in QxWidget are a simple aliases to some well known style properties, for example: color, backgroundColor, ... The one difference is, that you can configure these properties on an uncreated instance of QxWidget. This way you should be able to prefconfigure the full widget before adding it to any parent. This commonly speed-up things.

Layout

qooxdoo comes with a extensive layout engine in QxWidget. (Grids and other layouts components are currently missing.) It is possible to place widget with coordinates in the document. In a real QxClientDocument the document behaves like a canvas. There is no main scrollbar. You can layout with coordinates like top and left and even with right and bottom. All these properties allows percent values, too. Additional there is a value “auto” for the width and height properties of any QxWidget. “auto” means that the widget resize itself to the requirements of its childrens. Please note that you can only use two of the three properties on one axis at the same time (left + width + right is impossible, you will get an exception then).

Images

Image handling is one of the most used functionality of modern graphical user interfaces. qooxdoo support all the major image formats supported by webbrowsers, including cross-browser PNG-transparency. All images that are requested by a QxImage instance will be preloaded and cached before. If you use QxImage you are able to add listeners to “load” or “error” events emitted by each QxImage instance. This bring you the control back to your application.

Atom

If you have a look at todays graphical interfaces, many parts of them are build with a widgets which consists of a text and icon. Many times you are able to toggle for example if buttons look like pure icons or like a combination of both text and icon. QxAtom is the solution for all these widgets. It is the basic for many other advanced widgets (like the QxToolBarButton).

第一眼看上去，很像Bindows;
从API的使用来看，更像Bindows把API的Bi前缀换为Qx.

说实话，我非常怀疑这类仿windows控件用户的接受能力。

为什么Bindows不会成功:
http://blog.csdn.net/mechiland/archive/2005/01/19/259136.aspx


前天Buffalo发布了，专门为现有的web应用添加amowa/ajax特性：
http://www.amowa.net/buffalo

也许我落伍,但在我的印象中 bindows 似乎是不能跨浏览器的. 而 qooxdoo 的例子在我的 mozilla 中跑得很好.

buffalo似乎不错.做东西的时候,可以考虑拿来用用.

我最近也非常关注 AJAX 方面的动态。这代表着 XHTML/CSS/JavaScirpt/XMLHTTP 等一系列相关技术的复兴。我曾经用
The mummy returns 来形容这一趋势。

大家可以看看这篇文章：
Ajax: A New Approach to Web Applications
http://www.adaptivepath.com/publications/essays/archives/000385.php

通过我们这里一年多来对于 XMLHTTP、JavaScirpt、RIA 等技术和架构的讨论，其实我们最终也可以得到完全相同的结论的。AJAX 的可行性是不容置疑的，已经被我们这里一些勇于实践的开发人员的经验（我的经验，还有很多使用 JS+XMLHTTP+XSLT 的人的经验，给自己的脸上贴点金，呵呵），以及最近的 Google Map 等伟大的应用（体验一下 Google Map 的速度，你就知道我为什么说伟大了）所证实，还证实了基于 Web 标准进行创新是一条光明的大路。我的同事 ly 在三年前就采用了这种开发模式，并且把它的好处介绍给我，我后来又在这里一再宣传使用 JS+XMLHTTP 做开发的好处。因此我对于现在出现的 AJAX 一点也不感到奇怪，只是对于这种开发模式到现在才开始流行感觉有些遗憾。以前国内大部分的开发者只知道一味地迷信 J2EE，迷信 .Net，把自己限制在犬儒式的对大厂的盲从上，而不愿意自己去创新。现在出现的 AJAX 对于国内的开发者是一个启示，也是一个教训。共产主义是等不来的，无论是 M$、IBM 还是 Sun 都不会把共产主义的幸福生活拱手相送。并不是技术本身不行（例如在一些人看来似乎已经完全过时了的技术 HTML/CSS/JavaScript），其实还是人不行，再好的技术给你也做不出好东西来。
相对来说我更加看好这方面，而不是私有的解决方案如 XAML 或者 Flash 。这些技术的组合现在既然已经有了一个新的名字 AJAX，以后我们就把这些技术叫做 AJAX 好了。我的预测是 AJAX 会成为所有 RIA 解决方案中强有力的一个竞争者。

关于 AJAX，我们将来有必要进行深入而广泛的讨论。

至于说未来（几年后），我有个感觉，更简单的 “RSS等 语义/内容 + WebService Client” 将大行其道。这恰好就是MS XAML 的“桌面即浏览器”的提法。那个时候，浏览器将不会作为容器，而是作为一个内置插件使用了。不过，既然是未来的事情，谁也说不准。目前也不宜多讨论。

目前一段时间内，浏览器消亡之前的这段时间。我以前在另一个帖子里面，发表过意见，也倾向于AJAX。好处就是从HTML -> XMLHttp 的成本、学习曲线 比较低，代价不太大，过渡很平滑。而Flash则要求抛弃原有的HTML UI，用Flash表示，这对具有HTML基础的技术公司来说，代价还是不小的，需要换上一批Flash设计人员。

单从技术上来比较，Flash RIA 和 AJAX 都可以实现客户端 主动流程控制，即当前UI的URL不变，Script主动请求服务器数据，替换某些页面。
只是Flash RIA在 在线设计编辑（及相关的桌面控件）方面的强大优势，AJAX是无法比拟的。毕竟，Flash相当于一个具有完整桌面控件的客户端。
流程定制，零件配件图纸调整，甚至需要高级控制功能的在线编辑文本，等等。Flash RIA具有无可比拟的优势。我在另一个帖子里写，Flash RIA主要还是在设计领域发扬光大。

关于AJAX，有几个问题一直有点疑惑。

1. DoS （拒绝服务）攻击
据说这是因为XMLHttp 向服务器传输数据量的大小没有限制，造成的。HTML Post的数据量有限制。
不过，既然Google Map都采用了XMLHttp，这个问题应该解决了。
我想知道，这个问题是怎么解决的？需要自己在服务器程序中判断数据量，进行控制？

2. XSL 浏览器支持。
Dlee 提到XSL，是不是指 在浏览器调用 XSL？
我只知道IE支持XSL，(MSXML)。Mozilla, Firebox的情况怎样？

3. XMLHttp标准
XMLHttp （MS的私货？）, XMLHttpRequest（Mozilla的私货？）, 目前或将来会不会成为统一的标准？

不必担心，Mozilla 从诞生的时候对于 XML 以及一系列 Web 标准的支持就比 IE 要好。Mozilla 对 XML、XSLT 的支持是无缝的（属于 Mozilla 的核心功能），而 IE 5.0 版本以后加入的对于 XML、XSLT 的支持是通过 ActiveX 的方式实现的，被讥笑为打补丁的方式。
Mozilla 在 2001 年就可以支持 XSLT 转换了（不过必须承认，确实比 IE 的实现要晚，相对于 IE 5.0 来说晚了将近两年。但是你要想想 Mozilla 在 1999 年是完全从 0 开始，没有使用 Netscape 4 的任何代码，你就知道 Mozilla 的进步其实已经是非常快了）。IE 5.0 对 XSLT 的支持不完全也不标准（同样，塞进了一些 M$ 的私货），采用的规范不是 W3C 的正式版本 （IE 5.0 开发过程中，XSLT 正式的标准还没有出来）。现在因为 IE 6.0 也走到完全兼容标准的道路上来了，所以如果都使用最新的版本，Mozilla 的 XSLT 和 IE 的 XSLT 使用起来几乎没有任何差别。

这个问题我说过很多次了。XMLHTTP 虽然不是 W3C 正式的标准（算是事实上的标准），至少 IE、Mozilla（包括 Firefox/Netscape，可能还包括一些基于 Gecko 的浏览器）和 Opera（在 8.0 版以后增加了对 XMLHTTP 的支持）三大主流浏览器都可以很好地支持。Mozilla/Opera 这些跟进的浏览器在提供的接口上都是尽力与 IE 的接口相兼容的。那么我们还有什么需要担心的呢？

Michael Chen 在04年底正式提出的"面向异步消息的WEB应用"
它们的实现基础都是一样的 javascript +xmlhttp,看了看buffalo,感觉封装的很好.


http://www.amowa.net/

而且现在有个很好的实现 buffalo
Buffalo: http://www.amowa.net/buffalo

好像AJAX这种方式调试起来不太方便吧

现在版本的 Bindows 跨平台、跨浏览器的特性都支持的很好，而且连与服务器端的通讯都封装的很好用了。不需要自己去直接调用 xmlhttprequest 来跟服务器段实现复杂的通讯。可以直接用封装好的 xml-rpc 客户端，非常方便。

Bindows 的性能确实太差。qooxdoo 的性能不错，生成一个 20000 行 5 列的 Listview (其实就是 Datagrid)约5秒钟(P4 2.4G, FireFox 1.5)，对该 Listview 进行排序不到4秒钟。