JSF JSR 2.0草案征集－－Java web开发你还会选择其他的框架吗？

今天在TTS上看到Joseph Ottinger 的文章 Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
发现 sun真的开始吸收现有web框架的优点了， 努力打造Java web 框架的领导者。 在JSF 2。0中 让人讨厌的xml配置文件将不存在。 JSF将便的更加易于使用。到JSF 2。0广为使用时候，你还会选择其他web框架吗？（对于遗留系统，maybe！） 详细情况请参考TSS上的文章。

据说要等到2008年发布JEEE6的时候才能正式出台，真正能用起来还不知道是什么时候呢……

只要JSF还用JSP Tag，就绝对不值得考虑。

不要和我说Facelet，换汤不换药的东西，只是做了一下语法转换而已。

因为一个Framework使用Tag就将其一棒子打死是不合理的。其实在某些方面Tag是有优势的。
Html语法太灵活，语法出错也不会报错。而tag则可以避免出现语法问题。
目前想要有更高级的封装，Tag还是必要的。
Tag的问题在于无法提供一个很好的WYSIWYG编辑工具，无法替代Dreamweaver。但其实对于大型应用，绝大多数
页面的风格是一致的，我们只需要制定UI标准，然后Developer套用标准开发就可以了。这要求UI框架能够提供Layout功能，而不是手工在Dreamweaer里布局。

其实我们的期望也就是能够随意替换view，使用jsf就必须使用jsp，这点太让人不爽了，希望2.0能够解决这个问题，比如说可以结合freemarker等，或者就搞成.net那样也行，之前jsf的标签的确太难搞了

jsp tag的致命缺点有三：

1、极难扩展
在页面扩展可重用片断，必须自己用Java编写自定义Tag。而这个工作对于模板语言例如freemarker来说是很简单的事情，即使可以自定义tag，也会造成tag泛滥，项目难以维护。

2、不能脱离Servlet容器存在
必须紧密藕合Servlet容器，造成View根本无法测试，无法扩展

3、无法动态切换View
对于类似博客网站是致命缺点，博客切换模板，要求根据程序的状态，动态切换整套不同的View，JSP Tag完全做不到这一点。

而这些功能对于类似freemarker，velocity模板语言来说，是很简单的事情。web编程发展到今天，JSP技术已经是一个极其落伍的技术了。JSF可以自己创造自己的模板技术，也可以利用现有的模板语言，但是他唯独死抱着JSP Tag不放，所以JSF没有前途。

高人为什么都这么偏激呢？虽然我也很讨厌JSP TAG，不过用JSP TAG也有它的好处－－大家想一想，为什么tapestry和wicket很难像JSF一样有那么多的类似VB、Delphi的可视化工具的支持？除了JSF是标准得到各大厂家的支持外，JSF的以JSP TAG来实现视图也为易于实现可视化IDE提供了一个有利条件，如果为netbeans的VWP写过几个可视化插件，就可以体会到这一点了。前些日子看ICEFACES这个JSF的AJAX实现，他很容易地把它们的实现放入到各个流行的IDE实现可视化的编辑了，当然现在JSF的可视化开发工具还很不成熟，JSF也不太成熟……

不要和我说tapestry和wicket根本就不需要这样的IDE，有dreamwaver就够了，这就像DHH当然说RoR不需要太多的IDE支持一样，现在Netbeans出了个支持RoR的功能，大家还不是一样地为之兴奋？高手是高手、程序员是程序员、产业是产业……

我一点都不偏激，如果你觉得JSP好，那么请你问答我上面提出来的三个关于JSP致命缺点的问题。

Tapestry的模板从本质上来说，如果提供可视化IDE，其难度和JSP Tag是等同的，至少不会比JSP Tag更难实现。同样，任何Java模板技术要实现可视化IDE，难度也不会比JSP Tag更高，实际上应该更低(因为不藕合Servlet容器，IDE对页面的解析编写起来更灵活，也更好测试)

最后你自己也说了，JSF的可视化工具不成熟。

Tapestry的缺点就是没有大型厂商的支持。
单靠一个天才独自奋战，商业推广很不利。
对于JSF我是极度不喜欢。

最近好像不只一次看到robbin说这句话了，哈哈，JSF做这类应用确实不太合适。JSF的View其实不与特定的视图技术想耦合，《JAVA SERVER FACES》一书中就给出了一种类似Tapestry的解决方式，实现起来非常简单，当然，这只是一种可能，如果SUN选择JSP TAG的话，其它的解决方案很难被广泛采用……JSF让人爱恨交加！