对于标记库，不想再说些什么了。jsf可能最大的毛病都在这个标记库上面，首先定义的标记在jsp中，并不起到相应的输出功能，而只是用来增加相应得组件。在jsf中，最上层的组件为UIViewRoot，基本上所有的操作都是需要围绕着此组件。而标记库的存在，只是为了简化相应的操作。如下的标记：

其实对应的java代码，如下：

也就是说没有标记库，我完全可以使用java代码完成。
    那么标记库的存在到底有没有意义，意义可能就在于简化相应的操作，想想html的属性是比较多的，如果每个都要用java代码去控制，那么可能对于应用来说，显得很不灵活，因为改代码毕竟没有改jsp来的快。而且代码需要重新编译。所以jsf的标记库存在也是有点意义的。
可是，现在的问题是，由于jsf本身就是规范，其实现也就会各有不同，对于每种实现都会带有自己的那一套标记库，随着标记库的增加，对于使用者来说，也是不堪忍受的重负。所以，有些时候，如果需要动态做一些配置，那么还是丢弃标记库，用java代码来完成吧。当然facelets，提供了一种方式，用于很灵活的扩展多个标记库，可是，看着那么多的标记，总是还有些头疼。

    其次，对于标记库来说，各个标记库的不兼容也是一个很大的问题。就拿jstl和jsf来说，jstl的变量声明，在jsf中肯定是没有办法解析的，同样jsf中的变量，在jstl中也不能认识。我指的是页面声明的变量，而不是session变量，如下的例子：

在dataTable中声明了变量record，但是在jstl中是不会认识的。
    可能这个问题，facelets已经解决了，主要facelets把所有的Elcontext中的变量都结合在了一起，使用自身的FaceletsContext。
不过，如果我只是需要简单的功能，还需要使用facelets，那么也就有点大材小用了。况且facelets也只是提供了类似tiles的功能。
最后，想说的是，虽然jsf目前的ide支持，比其他框架多多了。可惜，人家都是建立在相应的标记库上的，如果你定义了自己标记库，人家不一定会认识。所以标记库的存在，对于jsf来说，也许并不一定是好事情，可能sun觉得如果把jsp抛弃了，有点可惜。所以在升级jsf的同时，也升级了相应得jsp规范。
    个人觉得，也许模版技术，可能也会是一种选择，看看velocity和freemarker，觉得其比jsp有优势多了。