NetBeans+VisualWebPack到目前为止发现的问题

（可能还有人不知道VisualWebPack是什么，VisualWebPack其实是sun java studio creator2在netbeans的免费插件<http://www.netbeans.org/kb/55/vwp-index_zh_CN.html>，主要用于JSF开发，其拖拉式组件开发是其一个主要卖点。）


首先需要先说说JSF

1、尽管JSF是标准，但不见得标准就是好的。君不见EJB2的状况？像JSF这个复杂（指的是实现的复杂）的一个框架（相对于jsp、struts等），我怀疑它是否是另外一个ejb。而且虽然说JSF是标准，但每个厂商自己的实现多多少少都会有一些扩展（通常是组件的扩展），一个JSF程序一般很难在不同厂商的JSF实现中切换。

2、JSF的生命周期相对jsp来说比较复杂，虽然VisualWebPack已经简化了，但还是复杂，有很多时候我想取一个值（大多数情况是动态值），但是没有取到，我怀疑有一些bug（当然不排除我自己技术没到家），记得之前的项目大部分时间就是耗在这个取值的问题上。

3、JSF的组件设计如果不是使用IDE的拖拉式开发，工作量反而比直接使用JSP、Struts要多。IDE在JSF开发中显得尤为重要。

4、JSF的错误提示太多无用的信息，不能对错误迅速定位。

5、在ajax大行其道的今天，JSF这种把一切都包揽在server端的做法，我还真是有所保留！虽然有Ajax4JSF项目，但这个项目好像不是标准来的。

6、相对与ASP.NET和Tapestry，JSF对HTML的侵入性比较大，令Dreamver这些优秀的网页设计工具无用武之地。



现在来说说NetBeans+VisualWebPack：

1、项目、资料、社区的支持度：现在使用JSF开发的项目还比较少，用NetBeans+VisualWebPack的就更少了。同时，由于VisualWebPack的出现比较晚，相关资料实在太少了，就算它的前身sun Java Studio Creator2的资料也是很少。缺少成熟的、稳定的、可持续的资料、社区的支持，如果出了问题，还真不知如何解决呢。

2、团体合作：（1）与美工比较难配合。我们很难说服一个用惯Dreamvwear的美工转用这个VisualWebPack。其实也是不可能的，你没有理由要求一个美工去学习JSF、VisualWebPack的标签，可能有人会认为，即使只是使用VisualWebPack的拖拉式也一样可以做出漂亮的界面。不过正如没有一个美工不懂HTML的道理一样，不懂JSF标签的美工，做界面总会有点美中不足。（2）由于NetBeans+VisualWebPack对某些文件极为敏感，很多时候，把一个工程打包到另外一个机器的时候，往往不能打开；有时候还要解决包引用的问题（NetBeans说这个是它的优点，但我反而觉得是一个不足）；更加不用说使用cvs版本控制了。到目前为止，VisualWebPack给我的感觉就是很难做大项目。

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

4、组件性开发：VisualWebPack的拖拉式组件开发从表面上看好像是很方便，不过用起来却是诸多不足，如果某一个功能可以有现成的组件实现，那倒很方便，如果没有，那是一件很痛苦的事情（同时由于VisualWebPack组件相对不足，令这种痛苦更加升级）。桌面程序不同于web程序，一般人对他们都不会有额外的美工要求，基本就是堆上组件就可以了。而web就不同，情况要复杂得多，经常有千奇百怪的要求，这种要求，通常用javascript实现可能比较容易，但由于VisualWebPack偏重于server端以及生命周期的限制，注定它跟客户端的javascript比较难结合，换言之，web的特殊效果也就很难实现。比较常见的是菜单、IFrame等。

5、与旧有项目结合：我们以前已经习惯了spring+hibernate做底层，现在发现VisualWebPack跟他们集成在一起好像问题比较大（或者说，处理系统分层比较麻烦）。例如，VisualWebPack的表格组件，对数据库的操作都推荐使用那个DataProvider。到目前为止，我们还没有找到集成的方法（还望高人指导）。另外，VisualWebPack里处理数据库的DataProvider用得最多得是CachedDataProvider，这个东西也真够古怪的，sun默认的例子是把数据缓存到Session里面。我真搞不懂，为什么sun那么喜欢把数据缓存到Session里面。

6、历史的倒退：（1）JSF有值绑定和控件绑定两种绑定方法（不知是不是这样叫），VisualWebPack默认是控件绑定的，在取得用户输入值得时候，我发现这是一个倒退，因为我还是需要一个一个控件调用getText()，这种操作我觉得跟request.getParameter倒是没有什么区别（可能就是增加了验证和类型转换吧）。（2）JSF刚出来的时候就嘲笑Struts的action必须要继承Action，因为JSF的managed bean是一个普通的java类（POJO）。但VisualWebPack现在的managed bean却走回struts的旧路，需要集成AbstrackPageBean。

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

8、其余问题：（1）VisualWebPack基本上是抛弃jsf的标准组件而使用自己的一套组件，这样多多少少会增加一些学习成本（不过这点也说不上是缺点）。（2）jsp文件对应的java文件，里面有一大堆的getter/setter，把源代码搞得很乱，同时，很难从IDE的“成员试图”中迅速定位。（3）NetBeans由于是使用Swing，字体显得比较丑。同时，字体边缘会有一些模糊。（4）有时候，修改了jsp文件或者java文件后，可视化设计就不能使用，由于提示不足，很难知道错在哪里，有时甚至需要重建页面。


谈就谈到这里，希望高手们都来说说自己的观点，并指出我的不足，谢谢

现如今连SUN自己在推动JSF的时候都不像以往那般卖力了，可见JSF的日子确实不是很好过啊……

另外，贵公司是新招揽会JSF的人加入团队，还是自己在摸索中掌握它呢？

自己探索

我们公司正在用JSF+SPRING+HIBERNATE开发一套工作流驱动的协同办公系统，虽然开始感觉JSF十分的别扭，可是项目进行三四个月后项目组成员基本上都能十分熟练的使用JSF，个人认为关键是对JSF底层的理解和各个生命周期阶段的深刻了解！

不知楼上是用什么IDE？

ASP.NET也很烦的，不过好处是有好的IDE和有MS这个官方！
JSF还没打算用，不过正如struts，就算被批斗得体无完肤，但是许多人用起来还不是一样很顺吗？
精通了，也就觉得不错了！
金蝶有个脸谱，可以看看！是通过验证的！

JSF用用,还是不错的,要想用完JSF,必须学会自己写组件

觉得jsf不会起多大浪，用过几次，慢的要死～～～，就这点就对它的前途是个巨大的打击！！！不过从nb网站下到一些老外的演示flash，只有一个感觉：老外的机器配置太高了！！！googlemap都不带停的何况jsf！！～～～所以个人感觉jsf国内来说基本没有什么用武之地～

还有就是复杂，学习的时间较长～～～
如果不能用dw来编辑它生成的页面，那几乎就没有多大的用武之地了～～～毕竟做web开发的dw是个必要的工具，不可能页面的样式了什么的还要去手工的编码！！！

觉得jsf不会起多大浪，用过几次，慢的要死～～～，就这点就对它的前途是个巨大的打击！！！不过从nb网站下到一些老外的演示flash，只有一个感觉：老外的机器配置太高了！！！googlemap都不带停的何况jsf！！～～～所以个人感觉jsf国内来说基本没有什么用武之地～

还有就是复杂，学习的时间较长～～～
如果不能用dw来编辑它生成的页面，那几乎就没有多大的用武之地了～～～毕竟做web开发的dw是个必要的工具，不可能页面的样式了什么的还要去手工的编码！！！

sorry 还以为没发成功～～～发了两次。。。。