发起关于XUL应用于“web”应用的讨论吧！

最近这一个星期浏览了一遍XUL tutorial以及一些spec。
XUL提供的众多组件确实有巨大诱惑，另外简洁的语言规范也很具吸引力。
我想象中的“XUL”应用是：界面设计可以更好的与 服务端业务逻辑分离，
看了XUL中rdf:datasouces的设计，我觉得可以独立界面设计，界面所需要的数据采取拉模式从服务端取出来，这点很类似于C/S模式。
template可以在某种程度上等效于Velcoty或者Freemarker，利用它可以动态构造比较复杂的界面结构。
事件处理机制可以结合JS优势 ，部分实现JS+xmlHttp功能。
按照上面的分析，我想象中的XUl应用应该是

XUL 界面 -----> RDF数据 (rdf:datasouces)------------->服务端 业务逻辑
因为，XUL提供了丰富的事件处理机制，那么我觉得可以将一部分独立于服务端数据查询的业务逻辑分离到XUl的事件处理中。
可以这样重新扩展：
XUL界面-----〉           RDF数据 --------------->服务端业务
XUL客户端逻辑--->  


然而，因为RDF是一种特定语法格式的xml文档，所以需要一个比较复杂的转换模块以将服务端对象层次转换为XUL可以理解到俄rdf格式，这个工作量会比较大。

这不得不让我回忆起以前用veloctiy写界面的美好时光，现在我们不得不在界面所需要的rdf和服务端的对象层次做一个转换。

大家有没有成功案例可供借鉴，欢迎大家积极参与讨论。

关于 XUL 的成功案例，我来举一个。
Active State 这家公司熟悉 Perl、Python 的人不可能不知道。这家技术实力超强的公司是 M$ 的合作伙伴，有 M$ 的投资，是 Visual Python 的开发者。

Active State 一向是立足于提供跨平台的商业开发工具。Komodo 是他们非常成功的产品之一。Komodo 是什么？它是一个支持 Perl、Python、PHP、XSLT 开发的 IDE。Komodo 建立于 Mozilla 内核之上，其界面完全是采用 XUL 开发的。当我在 3 年多以前知道 Komodo 这个产品的时候我感觉到了惊叹。因为当时一大群人（包括我在内）还在国内某个 Linux 论坛上围绕 IE vs. Mozilla 的立场/路线之争互相攻讦不休的时候，老外不管三七二十一早就挽起袖子大干了。这件事情反映出来我们国内技术人员交流的缺乏，甚至至今仍然是非常缺乏交流。EJB 现在在国外已经遭遇了中年危机，国外的开发人员早就不争论 EJB 的优劣了，国内还是有很多人对 EJB 趋之若鹜。

闲话少说，Komodo 是不是一个成功的产品不是我说了算的，看看它得到的奖项：
http://www.activestate.com/Products/Komodo/awards.plex
而且在这个“XUL 名人堂”（Apps Hall of Fame）里面，Komodo 是排名第一的：
http://xul.sourceforge.net/mozilla.html

再介绍几本 Mozilla/XUL 开发方面的书：
Rapid Application Development with Mozilla
http://www.amazon.com/exec/obidos/ASIN/0131423436/102-7570822-0481700
Creating Applications with Mozilla
http://www.oreilly.com/catalog/mozilla/
Essential XUL Programming
http://www.amazon.com/exec/obidos/ASIN/0471415804/102-7570822-0481700
到 eMule 上搜索 Mozilla，运气好的话可以搜到上面这些书的。

谢谢您推荐的几本书！我都作了下载，准备好好啃啃！
我提的疑问主要是想了解XUL在我们传统web开发上的不同之处。
采用XUL不仅是对界面的一种彻底的改革，也是对服务端开发的 一个决定因素。
我想这跟传统的web开发还是很大不同底。

to firebody：
我想你只要理解了 WebService 的架构就可以很容易理解这种 XUL 的架构。我的理解是这样的：
在传统的 Web 开发架构中，因为 HTML 的早期版本的功能很弱（主要是缺乏强大的脚本语言），所以都是把浏览器当作一个瘦客户端（只做一件事情，单纯显示服务器输出的 HTML）来使用的。标准的 3 层结构，表示层、业务层、持久层的逻辑全部都在服务器端执行。为了解决好表示逻辑和业务逻辑相分离的问题，还出现了 MVC 架构。

经过了很多年的发展，HTML 有了很大的进步，出现了表现能力很强的 CSS，JS 的能力也已经非常强大。同时还出现了 XUL 等等其它的 Web 开发技术。于是 Web 开发出现了一种新的胖客户端（Rich Client）的架构。在现在的这种新的架构中，表示层完全前推到客户端来做，表示逻辑完全在客户端执行。服务器端只有两层，业务层和持久层，现在服务器的角色就是类似于 WebService 中的业务服务提供者这样的一个角色。

这种新的架构有什么优点？优点就是现在分层更加清晰，表示逻辑放在客户端执行，与显示设备（例如：浏览器）结合得更加紧密，便于实现更好的界面和交互。服务器端的开发现在也得到了简化，可以更加集中精力于做好业务逻辑（实现 domain object）。这种新的架构对于表示层、业务层组件的积累都是有好处的。
有什么缺点？缺点就是现在这种架构对于安全性提出了更高的要求。可靠的用户身份鉴别和杜绝身份伪装就成为了必须要很好地解决的迫切问题。

看到你们的讨论，很感兴趣，我也来说说。我想请教DLEE几个问题：
1）你说rich client是从thin client发展过来的，其实rich client并不是什么新东东，从本质上讲就是传统的C/S结构而已，不同的是可以通过浏览器动态下载一个APP在CLIENT运行，而即使这样早期的APPLET也就可以做到了。当然我不想比较哪种技术好坏，我只想说你现在描述的这些rich client的优势，并不是新技术带来的，它早就存在，只不过我们把它找回来而已，可是我想不清楚这个轮回的过程有没有更深层的原因。
2）XUL我只了解点皮毛，我感觉它好像只是一个增强的HTML，不明白它的CLIENT端逻辑如何运行，比如，如果我需要按一个按钮的时候打开一个对话框界面，这个对话界面是作为完整的APP一次下载到CLIENT的还是临时去SERVER取？如果是后者，跟HTML的模式不是一样的吗？
3）我感觉象XUL这样的技术好像主要是针对独立桌面应用设计的，或者即使在WEB上也是要求浏览器支持XUL显示的，不知道能否将它用在HTML的WEB开发的场合？如果能有什么意义？

或者说，各种XUL是否只是和APPLET对等的技术，只不过具体特征不同而已。APPLET是字节码，在JVM中运行，而XUL是XML编写的界面代码，在具备XRE的浏览器中运行。

"2）XUL我只了解点皮毛，我感觉它好像只是一个增强的HTML，不明白它的CLIENT端逻辑如何运行，比如，如果我需要按一个按钮的时候打开一个对话框界面，这个对话界面是作为完整的APP一次下载到CLIENT的还是临时去SERVER取？如果是后者，跟HTML的模式不是一样的吗？ "

这个动作好像是客户端完成的,不请求server.

不过我不知道 xul是如何将数据发送到server端的.
如果依然要通过html转过去 优势就没有了. 麻烦 !

对soap知道的很少,用soap是否能直接将uml的信息直接发到服务器端处理,
如果用soap+xul方案 客户端是否需要一个可以发送soap的浏览器?