Visual Web Pack所知问题小议

　　（可能还有人不知道vwp是什么，vwp，Visual Web Pack的简称，是sun java studio creator2在netbeans platform的开源插件，主要用于可视化JSF开发，其拖拉式组件开发、DataProvider是其主要卖点。其网址是http://www.netbeans.org/kb/55/vwp-index_zh_CN.html）

　　首先需要先说说我对JSF的感受

　　1、jsf实际上是走ASP.NET的webform的路线，事件驱动、组件开发，我很少用asp.net，不过jsf则浅尝几次。总体来说，jsf目前仍然存在不少问题，我觉得jsf2或者jsf3才是它真正的推广时期吧。

　　2、在ajax大行其道的今天，JSF这种把一切都包揽在server端的做法，我还真是有所保留。

　　3、JSF的组件设计如果不是使用IDE的拖拉式开发，工作量反而比直接使用JSP、Struts要多。IDE在JSF开发中显得尤为重要。但遗憾的是，目前为止还没有一款可以称得上优秀的jsf IDE。

　　4、相对与ASP.NET和Tapestry、wicket等，JSF对HTML的侵入性比较大，令Dreamver这些优秀的网页设计工具无用武之地。jsf是使用标签的，我个人则是不怎么喜欢标签式的开发，使用标签并不比直接写java代码方便。记得JavaEye的老大robbin就对曾经对标签式开发大批特批。

 

　　现在来说说vwp：

　　1、项目、资料、社区的支持度：现在使用JSF开发的项目还比较少，用NetBeans+vwp的就更少了，相关资料理所当然不多了，就我目前所知，只有netbeans的官网有相关的资料。就算它的前身sun Java Studio Creator2的资料也是不多。缺少成熟的、稳定的、可持续的资料、社区的支持，如果出了问题，还真不知如何解决呢。

　　2、团体合作：与美工比较难配合。我们很难说服一个用惯Dreamvwear的美工转用这个vwp。其实也是不可能的，你没有理由要求一个美工去学习JSF、vwp的标签，可能有人会认为，即使只是使用vwp的拖拉式也一样可以做出漂亮的界面。不过正如没有一个美工不懂HTML的道理一样，不懂JSF标签的美工，做界面总会有点美中不足。到目前为止，vwp给我的感觉就是很难做大项目。

　　3、IDE的问题：不得不说，vwp还有很多bug，功能比较弱，组件偏少，而且耗资源很大，速度慢得有点受不了；跟Visual Studio相比，感觉还是有相当的差距。JSF本来对IDE的依赖就比较大，vwp的不足无疑是雪上加霜！

　　4、源代码的公开：尽管vwp是开源的，但我到目前为止还没有找齐它的源代码，即使是它的组件的源代码也不齐。另外，相关的高级教程比较少，例如，DataProvider的使用和改进等、组件的设计时的开发等，这使得对vwp的深入了解事倍功半。

　　5、组件性开发：vwp的拖拉式组件开发从表面上看好像是很方便，不过用起来却是诸多不足，如果某一个功能可以有现成的组件实现，那倒很方便，如果没有，那是一件很痛苦的事情。桌面程序不同于web程序，一般人对他们都不会有额外的美工要求，基本就是堆上组件就可以了。而web就不同，情况要复杂得多，经常有千奇百怪的要求，这种要求，通常用javascript实现可能比较容易，但由于vwp偏重于server端以及生命周期的限制，注定它跟客户端的javascript比较难结合，换言之，web的特殊效果也就很难实现。比较常见的是菜单、IFrame等。
　　另外，vwp本身的组件亦存在不少问题，最明显的是日期选择器Calendar组件，运行慢、生成的HTML代码庞大，是一个不及格的组件，用户需要自己重新写一遍它的render。

　　6、与旧有项目结合：我们以前已经习惯了spring+hibernate做底层，现在发现原有的vwp的分层式开发有一定的难度。在刚用vwp没多久，我就完全否定了其默认使用的CachedRowSetDataProvider，这个DataProvider在易用性、性能、扩展性等等都完全不合格，完全不能用于生产，由于这个CachedRowSetDataProvider实质上是vwp的一大亮点，现在亮点不合格，还真不知能说什么了。在这里说个题外话，在sun提供的vwp的例子里，数据、缓存、页面传递的参数等等都喜欢放在SessionBean里。过量的、不恰当的数据放到Session里的缺点是显然易见的。后来我不得不自己重新实现一个DataProvider来实现我习惯了的分层开发。

　　7、风险成本：无论是从人员贮备、资源文档、厂商支持、安全稳定来说，相当多公司使用vwp基本都是亮红灯的。风险成本不容忽视！