转载

选择JSF的理由：从UI组件开始

记得华为总裁任正非说过，华为是因为无知才走上通信产业之路的。我在2004年年中开始接触JSF时，也是因为无知。几乎没有Java经验，Web更是一片空白，写了一个半吊子的JSP程序后，我居然判了JSP的死刑，铁下心来钻研我的JSF去了。无知者无畏，说得一点也不错。
从JSP起步，第二级台阶，也许Struts是最合适的。没有复杂的概念，没有深奥的理论，容易理解，上手快，从JSP向Struts的过渡显得特别自然。这是Struts流行的原因之一。如果当时请教过任何一个Java高手，我十有八九会以Struts作为我的JSP替代技术，并且很有可能成为Struts的发烧友。可是，机缘巧合，我选择了JSF。
正应了那句俗语：“傻人有傻福。”采用JSF技术后，Web编程如有神助，一个月时间，我和一个刚毕业的程序员写出了一个规模不小的Web程序：126张数据库表，346个JSP页面，458K Java源程序，还包括84页的《需求规格说明书》和189页的《数据库设计说明书》。即便是桌面应用，这样规模的程序在一个月内完成，老板也该偷着笑了。其实，效率的提高，完全是JSF的功劳。正如Sun在JSF的规范中所宣称的那样，JSF极大地简化了Java的 Web编程。
首先，在JSF中，页面干净了许多。无需声明Javabean，也不用嵌入Scriptlet，没有多余的符号，只是一些扩展标签而已，看上去规范而不失优雅，让人赏心悦目。程序员多半是完美主义者，眼睛里容不得丑陋的代码，我认识的一些程序员，平时不修边幅，可以整个冬天都穿同一件夹克，袖口磨得油光发亮，但他们的程序却整洁得让人嫉妒。
其次，JSP中趾高气扬的Request和Response对象淡出了JSF。在典型的JSF应用中，程序员基本上没有直接操作Request和Response对象的必要，因为框架隐藏了对这两个对象的处理细节。不论是从Request中解码参数，还是将数据编码到Reponse中，都不需要程序员写任何代码，JSF知道该怎么做。当然，如果非要访问Request，JSF的隐含对象为程序员提供了可能。

JSF的UI组件
UI组件是JSF最具特色的组成部分。与桌面程序的UI组件不同的是，JSF的UI组件是服务器端的，但是，在JSF框架的支撑下，这些服务器端的UI组件，在程序员看来和桌面程序的UI组件没什么不同。我用的Jbuilder版本不支持JSF页面设计的所见即所得，当我拖动一个UI组件到页面上时，Jbuilder为我生成的，是一段标签文本，跟随着我的鼠标，放在指定的位置。一个服务端UI组件就是这样诞生的，其在页面上的表现形式也随之确定。
没有所见即所得当然有点遗憾，但对我来说，这已经足够了，因为把组件的Value和后台Javabean的属性进行简单的绑定，我就得到了所有需要的程序行为。页面显示和后台数据的同步、用户输入的转换、数据的有效性验证、错误信息的提示以及UI组件状态的保存和恢复，所有这一切不需要我写任何代码，JSF已经代劳了。
JSF的另一个特色是它的数据组件。我曾经很长时间使用PowerBuilder开发程序，熟悉PowerBuilder的程序员都知道，PowerBuilder最引人注目的是它的所谓数据窗口。并不好看的界面，笨拙的IDE，PowerBuilder单单凭借一个数据窗口，就吸引了大批程序员。PowerBuilder与数据库是天生的一对，长期使用PowerBuilder的结果，我养成了以数据库为中心的设计习惯。
这个习惯一直保持到今天，几乎成了我的嗜好，前面提到的126张表，就是最好的例子，换成别的程序员，也许30张表就够了。
所以，JSF的数据组件让我一见钟情。数据组件实际上包括两个组件，一个是UIData，一个是UIColumn。JSF将数据表看成是由若干个列组成的一个表格，而行的数目取决于数据源中数据的条数。这与PowerBuilder的数据窗口殊途同归。当然，数据组件不是直接从数据库中取得数据（实际上，设计模式也不允许程序员这样做），而是通过一个Javabean以resultSet的形式传递给数据组件。在JSP中，这样的程序逻辑够我折腾一阵的了，而在JSF中，这和生成一个文本输入框一样容易。
JSF数据组件的用途并不限于显示数据库表的内容，实际上，所有实现了List接口的对象都可以成为数据组件的数据源，这给Java的Web编程带来了极大的便利。而且，如果你想直接编辑数据表中的数据，JSF也可以做到，只需以可读可写的方式，将UIColumn的value属性和数据源中你想修改的属性绑定在一起，用户在网页上所做的修改，就会自动保存到数据源中。这样的功能，在JSP中，程序员都要深吸一口气才敢动手的。我的第一个JSF程序，之所以能在一个月的时间内完成346个页面，数据组件功不可没。

正文到此结束