對于標記庫，不想再說些什么了。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有優勢多了。