世界上有许多伟大的人，他们的发明改变了世界，但他们在有生之年，却无法看到自己的工作成果，也无法理解自己的工作成果给人类带来的巨大意义。 德国人乔纳森.古腾堡在欧洲首创活字印刷术，他的发明改变了西方世界，但是他却没能活着看到自己所发动的广阔革命。假如你在 1468年——古腾堡去世之时——告诉他，他于1455年出版的圣经将削弱天主教教会的权力；推动文艺复兴；使现代科学崛起成为可能；创造新的社会阶层； 他将一脸茫然，不明白你在说什么。
但是，今天，就在我们中间有一个人有着与古腾堡类似的成就，他却活着看到了自己的工作成果。他就是提姆.伯纳斯.李（Tim Berners-Lee），他发明了一套系统，将互联网变成出版媒介。
1955年6月8日，伯纳斯.李出生在英国伦敦的西南部，他的父母都是英国计算机界的名人，曾参与了英国第一台商用计算机的研制工作， 他从小便耳濡目染。但他真正开始研究互联网是在加入日内瓦的CERN（欧洲粒子物理研究所）后。作为一名软件工程顾问，他编写了一个名为 “Enquire”的信息处理工具，它就是World Wide Web（简称www，万维网）的最初概念。经过一番努力，1989 年，伯纳斯.李在Enquire的基础上提出了利用 Hypertext（超文本）重新构造信息系统的设想，并设计出供多人在网络中同时管理信息的超文本文件系统。 1990年，他在当时的NeXTStep网络系统上开发出了世界上第一个网络服务器（Web Server）Httpd和第一个客户端浏览编辑程序WWW。同年12月，CERN首次启动了万维网并成立了全球第一个WWW网站 info.cern.ch（至今仍是CERN的官方网站）。16年前—— 精确地说是1991年8月6日——伯纳斯.李在alt.hypertext新闻组贴出了一份关于World Wide Web的简单摘要，这个日子因此被标志为WEB页面在Internet上的首次登场。
自Web诞生至今，16年弹指一挥间，Web也由简单的信息发布媒介，转变成可交互的信息应用系统，而我们所处的世界，由于 Web 的存在发生了巨大的改变。信息查询与发布、电子商务、基于Web的应用系统，试想，我们身边哪一项跟互联网相关的应用离得了Web？
那么，作为推动Web应用持续发展的Web开发技术，又是怎样的？
Web客户端的主要任务是展现信息内容，而HTML语言则是信息展现的最有效载体之一。作为一种实用的超文本语言，HTML的历史最早可以追溯到上世纪四十年代。1945年，Vannevar Bush在一篇文章中阐述了文本和文本之间通过超级链接相互关联的思想，并在文中给出了一种能实现信息关联的设计方案。Doug Engelbart等人则在1960年前后，对信息关联技术做了最早的实验。与此同时，Ted Nelson正式将这种信息关联技术命名为超文本（Hypertext）技术。1969年，IBM的Charles Goldfarb发明了可用于描述超文本信息的GML（Generalized Markup Language）语言。1978到1986年间，在ANSI等组织的努力下，GML语言进一步发展成为著名的SGML语言标准。当Tim Berners-Lee（Web应用创始人）和他的同事们在1989年试图创建一个基于超文本的分布式应用系统时，Tim Berners-Lee意识到，SGML是描述超文本信息的一个上佳方案，但美中不足的是，SGML过于复杂，不利于信息的传递和解析。于是，Tim Berners-Lee对SGML语言做了大刀阔斧的简化和完善。1990年，第一个图形化的Web浏览器"WorldWideWeb"终于可以使用一种为Web度身定制的语言--HTML来展现超文本信息了。
1994年，Marc Andreessen新发布的Netscape浏览器大受当时上网一族的欢迎，因为Netscape 1.0 浏览器创造了一个记录，它比上一代的 Mosaic 浏览速度足足快了十倍，还独创性地使用密钥算法保证网上数据的安全，于是乎，Netscape 浏览器立刻占领了高达70%的市场，人人几乎都是用它上网。而微软适时地抓住了这一波的互联网热潮，成功地取得了 Mosaic 软件的许可，可以研发基于 Mosaic 的各种不同的浏览器，至此，NetScape 与微软之间长达数年之久的浏览器大战开始了，无疑，这场大战，有力的推动了 Web 客户端技术的发展。
1996年， Netscape浏览器在其2.0版中增加了对Java Applets和 Java Script 的支持。Netscape 的冤家对头，Microsof t的 IE 3.0 也在这一年开始支持 Java 技术。现在，喜欢动画、喜欢交互操作、喜欢客户端应用的开发人员可以用 Java 或 JavaScript 语言随心所欲地丰富 HTML 页面的功能了。
真正让HTML页面又酷又炫、动感无限的是CSS（Cascading Style Sheets）和DHTML（Dynamic HTML）技术。1996年底，W3C 提出了CSS的建议标准，同年，IE 3.0 引入了对 CSS 的支持。CSS 大大提高了开发者对信息展现格式的控制能力。1997年的 Netscape 4.0 不但支持 CSS，而且增加了许多 Netscape 公司自定义的动态 HTML 标记，这些标记在CSS的基础上，让 HTML 页面中的各种要素“动”了起来。1997年，Microsoft 发布了 IE 4.0，并将动态 HTML 标记、CSS和动态对象模型（DHTML Object Model）发展成了一套完整、实用、高效的客户端开发技术体系，Microsoft 称其为 DHTML。同样是实现 HTML 页面的动态效果，DHTML 技术无需启动 Java 虚拟机或其他脚本环境，可以在浏览器的支持下，获得更好的展现效果和更高的执行效率。今天，已经很少有哪个 HTML 页面的开发者还会对 CSS 和 DHTML 技术视而不见了。
同样值得纪念的还有Flash插件的横空出世。1990年初期，Jonathan Gay 在 FutureWave 公司开发了一种名为 Future Splash Animator 的二维矢量动画展示工具，1996年，Macromedia 公司收购了 FutureWave，并将 Jonathan Gay 的发明改名为我们熟悉的 Flash。从此，Flash动画成了Web开发者表现自我、展示个性的最佳方式。
与客户端技术从静态向动态的演进过程类似，Web服务端的开发技术也是由静态向动态逐渐发展、完善起来的。
最早的Web服务器简单地响应浏览器发来的HTTP请求，并将存储在服务器上的 HTML 文件返回给浏览器。一种名为 SSI（Server Side Includes）的技术可以让 Web 服务器在返回HTML文件前，更新 HTML 文件的某些内容，但其功能非常有限。第一种真正使服务器能根据运行时的具体情况，动态生成 HTML 页面的技术是大名鼎鼎的 CGI（Common Gateway Interface）技术。1993年，CGI 1.0的标准草案由 NCSA（National Center for Supercomputing Applications）提出，1995年，NCSA 开始制定CGI 1.1标准，1997年，CGI 1.2也被纳入了议事日程。CGI 技术允许服务端的应用程序根据客户端的请求，动态生成 HTML 页面，这使客户端和服务端的动态信息交换成为了可能。随着 CG I技术的普及，聊天室、论坛、电子商务、信息查询、全文检索等各式各样的 Web 应用蓬勃兴起，人们终于可以享受到信息检索、信息交换、信息处理等更为便捷的信息服务了。
1994年，Rasmus Lerdorf 发明了专用于 Web 服务端编程的PHP（Personal Home Page Tools）语言。与以往的CGI程序不同，PHP 语言将 HTML 代码和 PHP 指令合成为完整的服务端动态页面，Web 应用的开发者可以用一种更加简便、快捷的方式实现动态Web功能。
时至今日，PHP依然是最流行的Web开发语言之一。
1996年，Microsoft借鉴PHP的思想，在其Web服务器 IIS 3.0中引入了ASP技术。ASP使用的脚本语言是我们熟悉的 VBScript 和 JavaScript。借助 Microsoft Visual Studio等开发工具在市场上的成功，ASP迅速成为了Windows系统下Web服务端的主流开发技术。
当然，以Sun公司为首的Java阵营也不会示弱。1997年，Servlet技术问世，1998年，JSP技术诞生。Servlet 和 JSP 的组合（还可以加上Java Bean 技术）让 Java 开发者同时拥有了类似 CGI 程序的业务处理功能和类似 PHP 的HTML 嵌入功能，此外，JVM 技术的发展与优化也大大提高了 Servlet 和 JSP 的执行效率——这也正是Servlet和JSP被后来的J2EE平台吸纳为核心技术的原因之一。
Web服务端开发技术的完善使开发复杂的 Web 应用成为了可能。在此起彼伏的电子商务大潮中，为了适应企业级应用开发的各种复杂需求，为了给最终用户提供更可靠、更完善的信息服务，两个最重要的企业级开发平台—J2EE 和 .net 在2000年前后分别诞生于 Java 和 Windows阵营，它们随即就在企业级 Web 开发领域展开了你死我活的拼争。平台之争让整个 Web 世界在最近的几年里不得安宁，但从某种意义上说，也正是这种针锋相对的竞争关系促使了 Web 开发技术以前所未有的速度提高和跃进。
J2EE是纯粹基于Java的解决方案。1998年，Sun发布了EJB 1.0标准。EJB为企业级应用中必不可少的数据封装、事务处理、交易控制等功能提供了良好的技术基础。至此，J2EE 平台的三大核心技术 Servlet、JSP 和 EJB 都已先后问世。1999年，Sun正式发布了 J2EE 的第一个版本。紧接着，遵循 J2EE 标准，为企业级应用提供支撑平台的各类应用服务软件争先恐后地涌现了出来。到2003年时，Sun 的 J2EE 版本已经升级到了1.4版，其中三个关键组件的版本也演进到了Servlet 2.4、JSP 2.0和 EJB 2.1。至此，J2EE 体系及相关的软件产品已经成为了Web服务端开发的一个强有力的支撑环境。
和J2EE不同的是，Microsof t的.net 平台是一个强调多语言间交互的通用运行环境。尽管.net 的设计者试图以.net 平台作为绝大多数 Windows 应用的首选运行环境，但.net首先吸引的却是 Web 开发者的目光。2002年，Microsoft正式发布.net Framework和 Visual Studio .net 开发环境。早在.net发布之前，就已经有许多Windows 平台的 Web开发者迫不及待地利用 Beta 版本开发Web应用了。这大概是因为，.net 平台及相关的开发环境不但为Web服务端应用提供了一个支持多种语言的、通用的运行平台，而且还引入了 ASP.net 这样一种全新的Web开发技术。ASP.net 超越了ASP的局限，可以使用 VB.net、C#等编译型语言，支持Web Form、.net Server Control、ADO.net 等高级特性。客观地讲，.net 平台，尤其是.net 平台中的ASP.net 的确不失为Web开发技术在Windows 平台上的一个集大成者。至此，伴随着ASP.net 的推出，.net 阵营似乎已经在Web开发技术上取得上风， 那么，反观J2EE平台在Web开发之上的成绩呢？
令人不解的是，J2EE Web开发技术依然停留在 Servlet/JSP/Struts 等层次上。Servlet 基于流的简单编程模型，注定只能够成为一种底层支持技术；JSP将HTML与 Java 代码混杂在一起的技术，依然停留在十年前微软 asp 技术所达到的境界；Struts 缺乏客户化组件模型、缺乏对非HTML展现技术的支持等天生局限，也无法使其成为J2EE 下一代Web开发框架。
随着时间的流逝，Servlet/JSP/Struts带给我们的并没有新颖的变化，而是长期的审美疲劳。
J2EE Web开发技术，期待着一次新的变革！
J2EE是一个开放的社区，是一个允许各种技术百花齐放、百家争鸣的社区，同时，也是一个遵循标准、推崇标准的社区。与.net 相比，J2EE 的标准是开放的标准，它并不是掌握在少数人或者少数厂商的手里，而是允许并鼓励人们参与标准的制定，并通过标准来规范与约束不同厂商的实现，从而有效保护客户的IT投资。
Apusic OperaMasks 首先是标准的，它遵循并实现JSF 规范，任何基于JSF技术构建的Web应用，都能够平滑移植到Apusic OperaMasks上；同时，它又是开放的，所有的源码，以及OperaMasks整个开发过程，全部通过开源社区OperaMasks.org 进行。
那么，作为底层支持技术，JSF是否能够承担起“下一代J2EE Web 开发框架”之重任？同样，有了标准与开放，是否就意味着 Apusic OperaMasks 能够引领Web开发技术的新潮流呢？
Apusic OperaMasks是一种不依赖任何具体展现技术的解决方案，它支持现有的Web标准，譬如HTML与WML，同时也为将来可能出现的新技术、新标准做好了准备。在Apusic OperaMasks中，所有的UI元素被封装成Component，而Component通过Render Kit进行界面的渲染，当系统需要支持其它展现层技术时，只需要替换Render Kit即可实现。
当AJAX出现之后，人们意识到Web应用可以更加丰富多彩，于是各种RIA技术方案层出不穷，目的是要在AJAX这种“过渡”技术的思想指引之下完成下一代Web技术的变革。面对未来可能的新技术，很多用户和开发者在迷茫中观望，对JSF并没有抱多大的热情，认为JSF也是行将被淘汰的技术。事实上这种概念是错误的，JSF是一种和具体展现技术无关的技术。在Apusic OperaMasks中唯一和具体展现相关的部分是Render Kit，而Render Kit的可插拔的性质决定了Apusic OperaMasks可以适应目前和将来的大多数RIA技术。每当一种新的RIA技术出现时，只需要针对这种RIA技术编写一个Render Kit，这种新的RIA技术立即就能在Apusic OperaMasks中获得支持，而以前所写的应用不需要做任何修改。
Apusic OperaMasks为任何新的展现层技术做好了准备！
Ajax是当今红得发紫的技术，它改变了人们对传统Web应用的不佳印象，但同时，它的开发成本与维护成本过高。于是乎，各种各样的Ajax组件与框架应运而生。与Apusic OperaMasks相比，这些Ajax组件与框架所解决的问题，是简化Ajax的开发；Apusic OperaMasks则是使Ajax变得透明，是“干掉”了Ajax，用户甚至不需要知道Ajax的存在，而应用是自然而然的Ajax Enable的应用。
Apusic OperaMasks是世界上第一个“原生支持Ajax”的JSF引擎。其它常规JSF引擎（譬如MyFaces）往往是通过提供一些特殊组件库来完成对Ajax的支持，而Apusic OperaMasks则在引擎级别提供了对Ajax的原生支持。
举个简单的例子，在MyFaces中，为了达到Ajax效果，需要利用Sandbox子项目或者其它扩展组件，常规的标准JSF组件永远无法具备Ajax特性。但这些标准JSF组件，却可以在Apusic OperaMasks引擎上获得截然不同的效果：任何利用标准JSF组件构建的应用，只需要配置一个参数，就能够在Apusic OperaMasks引擎上获得完整的Ajax特性，包括与服务器端的异步交互、页面的局部刷新等。
<application>
<default-render-kit-id>AJAX</default-render-kit-id>
</application>
换言之，仅仅将上述参数中的default-render-kit-id置成AJAX，Apusic OperaMasks就能够让标准的JSF应用具备Ajax特性！
有点像变魔术？Apusic OperaMasks是如何做到的？
我们说过：Apusic OperaMasks is “from earth to the moon, and ready for Mars”。Apusic OperaMasks不仅提供了默认的HTML_BASIC的Render Kit，还提供了内置的Ajax Render Kit。因此，我们只需要将系统默认Render Kit置成Ajax Render Kit，整个应用就自动变成Ajax Enable的应用！
Ajax组件库是为了简化Ajax的开发（譬如ajax4jsf），而Apusic OperaMasks则是“干掉了”Ajax。对OperaMasks的用户来说，应用对Ajax的支持是透明的，你所写的任何一个JSF应用都支持AJAX，但不需要编写任何JavaScript代码，甚至不需要了解AJAX的原理。举个简单的例子，用户希望点击一个按钮，web页面产生一次Ajax请求与响应并更新某个text文本框时，通过ajax4jsf，我们需要在页面中指定：
<h:outputText id="dup" value="#{bean.text}" />
<a4j:commandButton reRender="dup" value=" Submit"/>
用户不仅需要记住额外的tag用法，还需要知道此Ajax请求需要更新页面哪个控件的值。而通过Apusic OperaMasks技术，用户只需要采用标准JSF组件的写法：
<h:outputText value="#{bean.text}" />
<h:commandButton value="Server Submit" />
然后，用户只需要指定此form的Render Kit是 Ajax，或者在配置文件faces-config.xml中，将全局Render Kit置成Ajax即可。用户无需记住其它tag的用法，也无需了解更新哪些控件，甚至根本就不必要关心什么是Ajax！
同样，这个世界还存在许多Ajax Framework，譬如dojo。我们并不否认这些Ajax开发框架的优秀，但是，与它们的优点同样明显的局限之处是：dodo之类的Ajax开发框架仅仅解决了客户端的问题，对任何服务器端逻辑，dojo无能为力。J2EE是一个整体，它不仅需要解决表现层问题，也要解决数据层和逻辑层的问题，JSF是JavaEE 5.0的一个重要组成部分，这就使得Apusic OperaMasks不仅可以创建丰富的客户端体验，同时可以和JavaEE应用服务器结合，从而建立强大的服务器端逻辑绑定。
与此同时，Apusic OperaMasks提供了部分特殊组件，以更有效的支持Ajax特性，譬如：
renderGroup：能够改造过时的应用，使其支持AJAX。在AJAX出现之前或基于其他JSF框架所编写的组件或应用有时并不能很好地运行在OperaMasks中，renderGroup能够为这些组件提供一个AJAX的渲染环境，使其达到AJAX的运行效果。
updater：装载和刷新页面的一小部分，使页面变成桌面。我们可以将页面的某些区域定义成一个独立刷新区，这些区域具有独立的交互环境和生命周期，当在这些独立区域中进行交互操作时他们被单独刷新，页面的其他部分不受影响。你可以单独开发和调试一些小应用，然后用updater将这些小应用组装成一个完整的应用。使用这样的技术将不再需要购买昂贵的Portal Server，在运行的时候和Portal没有什么区别。
event binding：如果必要，可以在服务器端处理客户端事件（譬如当某个客户端事件需要从服务器中获取数据进行响应）；
client validator：本该由服务器处理的数据校验可以在客户端执行。JSF默认提供了许多数据验证器，常规JSF引擎的实现总是在服务器端进行验证，这样的话，每次与服务器的交互总是会带来一定的性能损失，而Apusic OperaMasks能够在不更改代码的情况下，在客户端进行数据验证。
总而言之，Apusic OperaMasks对Ajax的支持是原生的，是从引擎级别予以支持的，在Apusic OperaMasks中，Ajax is Everything！
Apusic Operamasks提供了许多丰富的组件，我们称之为“Rich Components”。无须赘述的是，这些Rich Components从骨子里提供了Ajax的支持。在这里我们没有重新发明一次车轮，而是采用了广受好评的Ext JS（http://extjs.com）来实现Rich Components，但OperaMasks和Ext JS之间的联系并不紧密，如果必要，完全可以通过更换Render Kit的方式用其他的富客户端组件库来代替。这些组件都是面向数据的，可以用JPA、Hibernate、或直接用JDBC将数据准备好，交给这些组件去展现。同一组数据可以用不同的组件来展现，无论是DataGrid, DataView还是Chart，对数据的展现过程都是一样的。当数据需要更新时，通过AJAX和JSON完成与服务器的交互。我们有：
Apusic OperaMasks是基于JSF规范的， JSF从规范中便对工具预留了支持的空间。同样，Apusic OperaMasks不仅提供了引擎、组件，我们还有与之相辅相承的集成式开发工具：Apusic Studio。
作为集成式Web开发工具，什么是其最主要的核心功能？可视化设计？重要，但又不是全部。对Web开发初学者来说，可视化的页面设计器是能够降低Web开发学习曲线的有力武器，但真正有经验的人，却绝不依赖于设计器。真正熟练的、富有经验的Web开发人员，所需要的是一款细节考虑完善、开发过程流畅的工具。他们通过可视化去了解工具，但通过细节与开发流畅性去决定是否喜爱这款工具。
Apusic Studio提供了世界一流的可视化Web设计界面，同时，Apusic Studio又是世界上第一款将开发、配置、部署、监控等过程完美的衔接在一起的集成式开发环境！J2EE的Web开发原本是一个比较繁琐的过程，即便整个过程你很熟悉，但其复杂度也足以让人望而生畏，采用Apusic Studio，将使这一过程变得有如行云流水一般，除了每一阶段有向导帮助你快速实现以外，过程中的一些细节也自有Studio帮你照料得无微不至，当你需要完成什么功能时，你会发现它就在你手边，使你感觉开发Web应用不再是一种负担，而是一种充满成就感的过程！
布局是Web应用中的常见问题，Apusic OperaMasks优雅的解决了此类问题。我们有布局管理器。如图所示的BorderLayout能够将页面分割成多个部分，不同部分之间能够进行拖动、隐藏等操作。
同样，我们还提供了类Tiles的模版布局技术，解决Web页面的代码复用问题，并且，与Tiles相比，我们的解决方案更优雅，我们采用标准的JSF语法来完成页面布局的定义，使用户更易于上手，同时又避免了xml配置文件的繁琐。
Managed Bean是JSF中非常重要的概念，它是界面层与业务层之间的粘接器。JSF规范规定，必须在faces-config.xml文件中声明Managed Bean。如同EJB 3.0通过Annotation来简化ejb的配置一样，Apusic OperaMasks提供了以Annotation形式来配置Managed Bean的功能，包括提供支持Managed Bean声明、Managed Property注入等一系列的Annotations以避免维护faces-config.xml文件，极大的简化了应用的开发过程。
如果运行在Apusic应用服务器上，我们还可以在Managed Bean中通过Annotation进行资源注入，从而将Managed Bean与ejb/jpa等编程模型更好的融合在一起。
组件技术是解决软件复用问题的有效方案，Web开发同样如此。但我们却缺乏Web组件的构建基础。因为我们需要为其设定很多假设：它的技术是先进的吗？它的规范是标准的吗？它的实现是开放的吗？
无庸置疑，Apusic OperaMasks满足您的所有要求。并且，针对组件开发人员，它提供了若干基础服务，包括：
Ajax Engine：引擎级的Ajax支持，简化组件开发人员Ajax开发
Resource Manager：解决组件的资源管理问题
Skin Manager：提供组件的皮肤管理功能
OperaMasks.org是一个鼓励创新、鼓励分享的社区，任何用户都可以在Apusic OperaMasks上进行扩展，并形成自己的组件库，从而有效解决Web软件开发复用问题。
回顾OperaMasks相关技术，包括Ajax特性、Rich Components等，不难发觉，我们解决了界面展现层问题，以及展现层与业务逻辑层的粘接器Managed Bean，但我们缺少业务逻辑层所应该必备的一些基础服务，包括事务、安全、存储、分布式计算等，而这些，是Managed Bean所无法带给我们的。
幸运的是，就像 JSF 只是JavaEE的组成部分一样，我们不仅有 Apusic OperaMasks，还有久经考验的Apusic应用服务器。
Apusic OperaMasks是开放的技术，它可以运行在任何支持Servlet 2.5/JSP 2.1的Web容器上，但无疑，它与Apusic应用服务器的结合是最紧密的，而Apusic应用服务器也为其平添许多额外特性。
1) Managed Bean 与 ejb3/jpa 的结合：
在 Apusic 应用服务器上运行 Apusic OperaMasks时，支持在Managed Bean里面通过Annotation进行资源注入，从而能够将Managed Bean与ejb3/jpa很好的融合在一起，形成统一的编程模型，并由ejb3/jpa为Managed Bean提供事务、安全、存储、分布式计算等基础服务。
2) JSF状态的传递
JSF技术需要在客户端与服务器端之间进行状态的维护，这就意味着双方之间的交互可能更频繁，数据量更大。Apusic应用服务器为其提供了许多额外的特性增强，包括基于NIO的多路复用技术提升并发处理能力；基于gzip形式的状态压缩技术降低网络流量等。
Apusic OperaMasks是建立在 Apusic 应用服务器之上的，并与Apusic应用服务器一起构成了Web开发完整解决方案！
这是一个最坏的年代，J2EE Web开发技术已经迟滞多年；这是一个最好的年代，J2EE Web开发技术的新变革留给勇于创新的人！
Apusic OperaMasks是标准的，它遵循标准并推崇标准；Apusic OperaMasks是开放的，它乐于将知识与国人分享，与世界分享；Apusic OperaMasks是勇敢的，它凭借自身的技术积累与沉淀，努力掀起J2EE Web开发之新变革！
采用Apusic OperaMasks的人以及投身于Apusic OperaMasks开发的人更是勇敢的，他们是Web开发技术的探索者与创新者，他们也必将凭借自身的勇气与智慧，发现一个勇敢者的新世界！
OperaMasks还真是不错
前些日在csdn就看老袁放下大话，言称是“最好的Java Web框架”。今日一见，还果真强悍。
楼上看来是JavaEye迷吧？本人也常去，那里的统治群体对JSF以及Sun的官方技术抱有极强的偏见，以致于走到ROR的路线上去了。前阵子叫嚷着“Java将死”，最近才觉得有些不对头了，又开始念叨Java的好处。半年多前刚给JavaScript判了死刑，吹捧xaml，最近看DHH一篇文章出来，又回头啃Ajax。这种预言家式的治学方式实不可取。很多初学者本来对JSF热情很高，一到JavaEye就被帮所谓高手们吓回到Struts。其实在世界范围，JSF使用量现在仅次于Struts1.x（仅仅是因为JSF出来的时候Struts已成事实标准），且逐年上升。现在就断言“将死”，只怕是太早。 JSF本人用过好几个项目，总体表现良好。做简单页面非常容易，开发效率比之高手们吹嘘的WebWork不为低。而高手们反复攻击的毛病，无非是页面编辑时普通工具不能识别专用tag，这个问题其实除了难以上手的Spring MVC外都是如此。而只要机器好一点，JSF有专用工具可以解决这个问题，其它的则未必。 至于楼上所提的复杂页面问题，这一点多做Web的人都知道，有框架不如无框架。但90%的常规简单问题还是值得用框架的。本人用了两年JSF，认为它可以解决大部分Java Web问题，而今天本人运行了OperaMasks的Demo后，认为它可以解决大部分的Java-Ajax集成问题。
JSF沿袭的是Swing的技术路线。而Swing的技术架构非常优秀，在长期的实践中赢得业界广泛赞誉。以前本人用Swing的时候，总是抱怨其控件少。其实这是Swing实现完美跨平台所付出的代价。真正学明白了，在Swing超一流的基础架构上扩展个控件出来可谓轻而易举。最近本人在AbstractTableModel的基础上扩展了个Table控件，相当好使。这才搞明白，不是Sun的东西不好，而是以前自己水平不到。
老袁前些天说的大多数人是“没真正搞明白JSF”，这句话是说到点子上了。JSF标准自出来以后，各种第三方的类库层出不穷，充分说明JSF的高度可扩展性（一如其前辈Swing）。本人在很多地方用过myfaces，相当优秀。而老袁这个OperaMasks很好地解决了Java集成Ajax的问题，实在值得叫好！
前一阵子看到很多人吹捧的YUI-ext，从来没想到JSF也可以做到这种程度。大家与其看我等人无聊的对比与争执，不如好好运行Demo对比一下吧！ 顺便说句题外话，大多数国人向来不相信自己的IT技术人员能做出一流的东西，唯洋人马首是瞻。所以社区上像老袁、banq这类的一流高手反被冷落。现在老袁优秀的东西出来了，优秀的文章也出来了，连洋人也叫好了。大家是仍旧冷嘲热讽，还是真学实练，自己看着办吧。
To: “历史回顾变成了选择性失忆”的作者
不瞒您说，这篇文章是应公司市场部要求撰写的一篇市场味道较浓的宣传文章。但毕竟本人是技术人员，所以，在技术层面上对Web开发历史及目前的一些Web开发框架进行了一些回顾与点评。
技术对比是一件非常严谨的事情，由于时间紧，我们就没有把所有的Web开发框架进行一一点评，不妨就只把我们熟知的，并且也是目前最流行的一些技术框架进行了一些讨论。因此，您提及到的“选择性失忆”，并不是我们有意的失忆，而是我们精力实在有限，不想发表任何不客观的评论而已。
至于OperaMasks的思想和技术到底如何，其实自从我们开始做应用服务器开始，国人对我们的质疑就从来没有中断过，幸运的是，历经7年的发展，我们已经有足够的思想承受力。
我们只想静下心来，把这件事情做好，谨此而已。
再次感谢您对我们的关注。
张勇
关于GPL协议的变更
只是我们发觉，GPL对商业不够友好，而很多OperaMasks用户希望将AOM用到商业用途。
基于此，我们打算把GPL变更为LGPL。
难道这不是一种更加开放的态度吗？
张勇
从来不敢奢望用java做web能这样方便同时具备这样的效果
从来不敢奢望用java做web能这样方便同时具备这样的效果，看了演示之后很震撼，就凭这一点，赞一个！这是国人做出来的，再赞一个！
从来没有一种药可以包治百病。JSF只要能解决一部分开发者面临的大部分问题，这就很好。 实验室里的技术，投入使用，产生效益，给社会带来贡献——不求完美，只求实效！ 如果有更好的解决方案，拿出来，看到了就多赞一个——就是这么简单。
自己用java做web也有几年了，有些经历，后来证实，之所以开始时说它不好，原来真的是自己了解不够。而这次看到operaMasks，很震撼，也很振奋！ 祝愿OperaMasks发展的更好！
谈谈Operamasks和构件化平台的联想
安装体验后的感觉，前几年比较流行的几个构件化平台，上海XX公司的EOS平台，北京XX公司的Justep试图从业务建模或构件、SCA等角度出发解决Web开发的效率和重用、降低开发人员学习曲线。应用后很多开发人员感觉越来越不会用Java开发了。Operamasks的发展前景是什么？也要走到业务建模层次吗，不知道。技术架构和业务建模两个视角。很关心Operamasks将来不做什么。限于技术层次，还是要走到业务架构层次，请赐教
关注
这些工具都是“提高开发效率，降低准入门槛”的，越来越多的人不懂软件开发的本质是正常现象，因为有更多的、本来不懂的人涌进来了，稀释了软件高手在从业人员中的比重。 同样关注楼上的问题。
JSF真的有问题
我记得JSF是sun看到了asp.net比较古怪而搞的吧。asp.net这种固有的开发方式就是有问题的所以学习这种开发方式会也是非常的有问题的。 我看到过很多国内的asp.net的开发者，初级的最大的疑惑就是怎么把页面作的美观？美工MM作的页面怎么在这个上面布的时候是那么的难受？高级的开发者知道应该弄一些开发一些控件之类的，可是很多控件是在这个项命中能用在另一个项目中不能用的。让人非常的疑惑非常的难受。
我认为简化web的开发不在于破坏一系列的标准而建立起另一套标准。sun的标准和w3c的标准那个更“标准”？^_^毫无疑问的是w3c了，HTML连入门的小鸟都能看得懂，可是 jsf？所以问题的关键就归结在了我们如何去改造现有的广泛使用的标准（因为这个标准是事实的标准~小鸟鸟都知道怎么用。）而不是创造一个新的世界（这一点千万不要像伟大的比哥学习，人家失败了可以花钱修改~可以用钱宣传~甚至可以再提供一套解决方案。我们真的没有那么多钱） 现在的一些web标准是不是真的没有扩展的价值了？不一定~
任何建立在现有的广泛使用的标准之上的工具才是真正可能成功的工具。 winrar因为兼容winzip并且可以免费试用而击败winzip tcp/ip协议因为更加的实际而取代osi成为王者 现行的开发者更熟悉html，js之类的~我们是不是应该顺从这些（我并不是指裸奔，是有简化的方法的。）？是强迫他们使用新规则（花费巨大的人力物力财力不一定能成功~）还是“兼容”它们？
另外我提一下asp.net的事情，asp.net现在的开发方式已经让很多人不爽了~所以有了开源的框架Castle它的命并不好~没有人去理睬它~，不过现在微软似乎接纳了它，还聘它的创建者来作作微软的MVC，呵呵，那位朋友不乐意做了一个MonoRail）。 现在微软也觉得不爽了，也是微软的总开发经理scott gu决定开发MVC框架~ http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx
OperaMasks看起来很cool，就是不是在简化开发而是在强迫开发者学习一门新的规则~
差点忘记了
差点忘记了。 这个站是plone作的对吧~^_^~这个东西是个好东西~可是从02年到现在它的年龄那么大了还是没有普遍的使用，其中原因我不说也应该想到了。
历史回顾变成了选择性失忆？
看了前面的历史回顾，写得不错，我本对后面的java web framework部分充满希望，不料，第4节居然就寥寥几句，java世界如此多的开源和商业的web framework，居然作者提都未提，只说了servlet/jsp和古老的struts，连ASP.NET的描述也比它多。难道作者认为所有的读者都还停留在2001年？我看读者没有“审美疲劳”，是作者“记忆疲劳”了。
我不相信红岗和张勇你们没有看到过java世界web framework的欣欣向荣，仅仅列入Apache的就有webworks、tapestry、turbine，还有cocoon。也不用说像gwt、echo、dwr、rife、zk等，哪一个不是名声在外，连你们熟知的Spring都有Spring MVC来插一杠子，你们居然全都视而不见？我只能认为你们是有意略过。这就是所谓“选择性失忆”。其他领域我们不说，但对于技术人员来说，这是很不应该的。
然而不谈这些java领域的web framework，不把OperaMasks放在这样一个大舞台上与其他java web framework做做比较，你们就自夸OperaMasks是“from earth to the moon, and ready for Mars”，号称“在技术和思想上傲视群雄”，这就更未免有些可笑了。有自信是好事，但是不幸的是，我们不止一次看到自信沦为自大狂妄甚或无知。OperaMasks是不是也会如此？我不知道，我也不希望如此。
下面谈谈技术。
说老实话，OperaMasks要自夸，首先你要证明JSF技术的先进性。作为一个有超过8年经验的web开发者，我对于Sun官方的JSF，甚至Java社区众多的MVC框架和一些新兴框架，都有着深深的疑虑。众多企图抹平网络编程与桌面编程的鸿沟，企图让开发者完全不用了解B/S原理，企图服务器端掌控一切的所谓“简化”，实际上真的是web开发的方向吗？B/S的请求响应机制，HTTP作为无状态协议等，都是web编程的固有约束（参见著名的REST论文），而以ASP.NET和JSF为代表的技术方向，实际上是在背离和打破这一约束的道路上越走越远。掩盖web编程“复杂性”的“简化”事实上能真正简化问题吗？实际上为了掩盖复杂性，也许底层付出了更大的复杂性的代价。许多框架的前提是，开发者不需要陷入这些plumbing，可能对于许多应用来说确实如此，但是一旦开发者被迫陷入必须处理一些设计者故意忽略的问题，他可能会发现陷入了巨大的困境中。微软的winforms和ASP.NET就是这样一种模式的典型代表，如果默认提供的那些控件够用，一切ok，但是如果你想稍作改变，extends一下，就会发现陷入大麻烦了，只好去买第三方控件。而你去看看那些第三方控件，全部是自行实现的，没有一个是从默认控件继承出来的。而这些第三方控件与默认控件是否能和平共存互相协调呢，很有可能不行，或者是会产生一些奇怪的bug，这全赖于第三方是否对其底层有足够的经验和能力。也就是说，表面的简单，换回的是开发者对于系统内部复杂性的理解力的丧失和自行扩展系统能力的严重下降，开发者对于第三方控件，最终也只能“以貌取人”，面对的风险是极大的。
JSF或者说OperaMasks会不会这样呢？这很难说，但是我不太乐观。因为我深知web客户端编程的复杂性，直接的客户端Ajax开发框架如prototype、dojo、YUI、ext等尚在努力，而服务器端连这一层都要掩盖。掩盖复杂性不是做不到，但是要把这多层复杂性以优雅的方式隐藏起来，并且还能在需要接触内部的时候，优雅的显露出来，简直是mission impossible，到目前为止，我还没有看到成功的。OperaMasks可以吗？存疑。这里有篇blog：http://canonical.javaeye.com/blog/106766，对于JSF有这样的结论：“所有问题的一个集中体现就是增加一个新的JSF组件绝对不是一件平凡的事情。”
我们再看看Render kit。说起来只要更换一套render kit，就可以Ajax enabled。理论上似乎可行，但是这很可能只是具有一点Ajax的皮毛效果而已。实际上，开发者丧失了许多控制，特别是架构上的控制。比如JSF能支持REST架构么？不仅是现实中，在理论上就存在困境。因为JSF的语义可能就与REST架构不匹配。
当然对于偶尔做web开发，以java编程为主的开发者来说，JSF是有吸引力，特别对于企业内部应用来说，也有一定实用性的。但是以web开发为主，特别是做大规模web开发的人来说，应该对JSF抱有警惕。因为，这种类型的开发简化，很可能是以各个部分之间的紧耦合为代价的。
我再摘录一段文字：“同样，这个世界还存在许多Ajax Framework，譬如dojo。我们并不否认这些Ajax开发框架的优秀，但是，与它们的优点同样明显的局限之处是：dodo之类的Ajax开发框架仅仅解决了客户端的问题，对任何服务器端逻辑，dojo无能为力。J2EE是一个整体，它不仅需要解决表现层问题，也要解决数据层和逻辑层的问题，JSF 是JavaEE 5.0的一个重要组成部分，这就使得Apusic OperaMasks不仅可以创建丰富的客户端体验，同时可以和JavaEE应用服务器结合，从而建立强大的服务器端逻辑绑定。”
事实上，你们所认为的局限性恰恰可能是我们认为的优点。为什么JavaEE要解决所有问题呢？会不会所谓解决整体的方案，实际上会把问题搞砸呢（最著名的例子是EJB）？如果把JavaEE限制在数据层和逻辑层，以web services（无论SOAP还是Restful的形式）提供出来，而由纯浏览器端技术来解决表现层，是否可能是一种更好的方案呢？比如REST架构所体现出来的松耦合、语义透明性、极高的可伸缩性，纯浏览器端Ajax框架所体现出来的高交互的用户体验、灵活性、以及不依赖於服务器端的互操作性。
对于JSF的忧虑或质疑，不是我个人，而是社区内普遍的声音，像是 What's wrong with JSF 之类的讨论已经不稀奇了，宣称 JSF is dead 甚至 officially dead 也随处可见。国外如此，国内也是如此。
最后，我赞赏OpearMasks的GPL开源和社区路线（但现在要更换协议，令人有点担忧）。Native Ajax支持确实也略有新意。但是这还远远不够，目前为止，说OperaMasks思想和技术有什么领先处，实在无法令人信服。我所看到的只是令人遗憾的选择性失忆。