Web表现层开发的思考（二）

三、组件化界面开发

目前有很多开发框架都突出表现层组件化处理的思想，流行的框架有Tapestry、Turbine、ECHO、JSF等，ECHO、JSF没有深入研究，不敢多说。

个人比较喜欢Tapestry，本来计划在工作流应用开发框架中，采用Tapestry做为主框架，后来因故没有继续，现在一直很关注这个项目。

Turbine，03年4月计划对Jetspeed进行改造，做一个支持拖拽、基于Web的门户配置工具，想的比较简单，结果发现这家伙是在Turbine基础之上的应用系统，分析了这两个系统后，还是放弃了原计划，就两个礼拜时间，进度要紧，只是简单的进行了汉化和样式改造，将用户认证部分和公司的产品进行了整合，做完后大家说怎么还不如上个版本的主界面，上个版本是项目组自己用JS和DHTML做的一个组件拖拽的界面配置工具，没有采用portlet标准，而且速度也比较慢，但是很漂亮。这件事让我们对Apache的印象也开始变坏了，呵呵。

但凡一项技术，如果有好的工具和丰富的资源库支撑，容易上手的话，那么它能很快使用和传播。

同样基于界面组件开发技术能否成功的关键，是组件库的丰富和设计工具的易用性，如果能有这样的产品出现，Web表现层的开发效率才能真正提高，JSF据说可提供可视化工具支持，而且Apache 的Jakarta项目组已做了很多JSF和Structs的集成工作，暂且看看吧，不知道什么时候能有好用的开发工具面世。

说起开发工具，让我想起一件事，那是01年的时候，我们承接了一个电子商务网站的开发，当时聘了一个项目经理，据说对Websphere Studio很熟，领导也要求用IBM的Websphere，他给我们演示了一个DB快速开发的例子，和PB的数据窗口类似，后来项目因故无法采用Websphere，这位PM没办法，只能和大家一样，用JSP编，最后的结果是代码质量最差的就是他，惨不忍睹。

题外话：
1、Struts

一直有同事问我：为什么不用Struts做应用开发框架？倒不是说它有什么不好，原因有2条：

很多地方它已经“陈旧”了，比如Filter和Dispatch，已经在Servlet2.3中形成了标准，成为Servlet容器支持的功能，如果是这样，Struts似乎应该进行修改以适应Servlet标准的变化。

表现层基于Taglib，延用公司现有的XML和XSL表现层实现方案需要进行改造，据说在和JSF集成，还是等发布了后再说吧。

现在经常和同事说，Apache的东西和它宣传的不一样，不能都信。Slide说它已经可以对文件进行版本控制，实际上没有实现，全文检索没有采用Lucene，当然它自己也没有实现这个功能，要用它必须自己改造；最可气的是Tomcat，4.0发布时说完全支持Servlet2.3标准，结果按照标准写出来的Filter和Dispatch程序，分开单独运行都正常，合在一起就无效，同样程序放在Weblogic上就没问题，到bug库里一查，还真有这个bug，一直拖了几个月都没有改，傲慢得不行，现在总算是好了，可是害得我们的当初的设计结构要做变更，好端端的程序明明是正确的，却不能用，把人气够呛。

2、微软和J2EE

微软做为PC系统软件的霸主，一直想进入由IBM、SUN这些公司把持的企业应用高端。而后者也想抢占PC平台地盘，双方都拿标准来压对方，各自推出的技术有些地方都很有趣。

后者通过定位论将微软死死摁在“低端”，从设计企业应用体系框架时就一心想绕开PC平台上的微软操作系统，将原来大家认为合理的服务器端进行数据处理，客户端进行表现处理的模式生生拉回到中央主机模式，但是B/S的致命缺陷是用户交互能力实在太弱，看看实在是绕不过去了，可是一直没有好的办法解决，都说微软的软件吃内存，可是看看IBM的，不必微软的少，客户也很理解，说JAVA开发的吗，就是吃内存！有时想这些公司怎么连个JSP的可视化开发工具都做不好？SUN对JAVA的贡献越来越少，除了一大堆可以学习“过度设计”的接口外。

微软则拼着命的想把一切东西，包括服务器端的软件都给Windows化，先是将各种功能往浏览器里塞，与Windows紧密集成，浏览器现在是一统天下了，OK，我在把这玩意给你淡化，把Longhorn操作系统当浏览器，用XAML来进行应用程序开发，没有什么B/S和C/S。

如果从企业快速应用开发角度上看，微软的开发工具所提供的功能确实很和程序员的口味，使用vb.net的Form控件进行Web应用开发，一个PB程序员能很快上手进行数据库开发，尽管他不是很明白体系结构，但很多时候这就够了。让他学习JAVA、Servlet、JDBC、模式，要他一切从底层做起，很多人都觉得干吗要用J2EE（现在所在公司里的程序员使用Delphi和PB做了这么多年的开发，没有快速开发工具让他们很难适应）？

02年底的时候我突然想干吗非要用DHTML、JS做这种东西，MSN大家用的挺好，大家没觉得不用B/S方式实现就很不好。毕竟我们不是在做网站，所有的表现都用网页是不是过了？

如果让我描述我心目中理想的架构，我想是这样的，微软的表现层技术，J2EE的服务端技术，通过XML格式数据进行交互，用不用浏览器不是关键。开发工具？希望Borland能实现。

牛人呀，俺跟一跟
1。tapestry我也很喜欢，很地道很好玩的东西，虽然没怎么深入研究过，但是只看了一下user guide，了解了一下原理就就觉得有搞头。他表现层的技术，很有点像xmlc,是我比较欣赏的一种方式，不果倒过来也是一种约束吧。我总觉得像jsp那样页面里嵌代码和加tag的方式不是解决之道。担忧也是有的，一个是没有好的ide支持，不容易做快速开发，配置文件一堆隐约觉得做团队开发和学习有点难度。另外一个就是缺乏商业公司支持。strust不怎么样，可是支持的公司多，所以很多人都觉得webwork好，但是用就是少，这是一个道理。缺乏广泛支持的话组件库就有点问题，何况现在还有jsf这个东西。
2。JSF其实不是什么新东西，同样的东西，salmon早就实现了，可是缺少广泛支持，也没有好的集成的IDE,所以这个严格意义上更像asp.net的所谓jsp.net发展也很缓慢。如果这次jscreator出来真的和sun公司鼓吹的，和vs.net以墨一样的话，我觉得salmon/echo这些东西是没活路的.MS的东西用的人多，我感觉主要是2样，一个是ide整合的好，屏蔽掉大多数复杂的东西，另外一个是集成的现成可用的组件比较多，这2样加起来，新手上手快，1，2天就能搞出点东西来，虽然可能搞几年也不明白是啥东西。比起来，java世界更像是一种黑客提倡的精英文化，甚至在ec/idea出现之前，连ide都没有象样的，n多java程序员可都是用vi/ultraedit做开发的，呵呵。今天就要发布了jscerator了，呵呵。等着看吧
3。国内现在做这个的已经很多了。pb/.net/delphi + j2ee，中间用xml,技术上已经相当成熟了，pb可以用dw的外部数据源，.net的话，ado.net已经支持
xml了，所以用xmlhttp通讯应该也没问题，重一点的话可以用ws。
borland的东西还是不要指望了吧，一个是现在打击的太厉害。另外一个，我觉得看jb就知道了，borland已经失去创新的能力了，我弄了个c#builder,用了一天就扔了，太滥，除了建模，实在看不出比vs.net强在哪。
我倒是有个想法，ibm应该牵头用swt搞一套完整的前台组件库，特别是包括各种标单、数据处理的组件，那样的话是最强的，呵呵。ms的东西虽然简单，可是api太少，不爽呀
第三种方式目前最好的恐怕是mm的几个产品吧，有经验的可以介绍一下。

其实你还忽略了一个层面，就是XUL类似的东西，xform标准已初，mozilla和ms也都各自搞了一套ms的infopath号称是把office变成了开发平台也不知道是不是真的，看ppt有点吓人。flex也跟这个有关吧。
有牛人也来介绍介绍，给我们开开眼界。