canonical

一個技術的成功，在于最終占據了某個概念。當我們應用到此概念的時候，首先想到的就是這個技術實現，久而久之，形成一個自我證明的過程。而有些技術卻是在 其位無能謀其政，實在是讓人不得不為它扼腕嘆息呀。jsp tag正是這樣一種技術。有些人認為jsp tag只是jsp的一種擴展，只是一種syntax suger, 這正反映了此技術所面臨的一種困境。這里指出一些jsp tag的設計缺陷，并無貶低這種技術的意圖，只是希望拋磚引玉，引發大家對這種技術改進的探討。
引用:
jsp tag是服務器端的擴展標簽機制，它是一系列java服務器端技術的基礎。但其設計之初的幾個重大缺陷已經使得這種技術不堪重負。  

對比dotNet平臺我們可以知道，需要一種后臺標簽機制，jsp tag是唯一的標準（JSF等機制都依賴于此)，可它的設計給所有希望基于它開發的開發人員造成了巨大的困擾。實際上我對這個技術感到很失望，當然我們提 出了相應的替代方案。在我們的開發框架中使用的是重新設計的一套與網絡無關的xml動態標簽機制。我的觀點是基于jsp tag技術，無法開發出與dotNet的便捷程度相當的服務端技術，所以這是它作為標準的罪過。jsp tag不應該是jsp的補充，它搭上了xml這條大船，應該去走自己的路，而不應該成為應用上的雞肋。
引用:
1. jsp tag與jsp 模型緊密綁定，使得業務邏輯很難抽象到tag中。而且脫離了jsp環境，在jsp tag上的技術投資將一無是處。  

這里說業務邏輯可能是有些不妥，容易引起誤解。因為我的工作做在中間件層，所以我的原意是基于jsp tag開發一系列的擴展技術，比如緩存等。我們的xml標簽技術是與jsp模型無關的，在前臺用于界面渲染，在后臺用于工作流描述。而且很方便的就可以與 其它xml技術結合，比如集成ant。

引用:
2. jsp tag的編碼邏輯非常繁瑣, 特別是寫loop和容器類標簽的時候。在2.0之前不支持從tag本身產生tag更是應用上的主要障礙。  

這絕對是個重大問題，試問多少人自己去開發jsp tag呢，多半是用用別人的成品。編制困難其實就是否定了界面元素的重用。很多人推崇Tapestry, 其實如果jsp tag技術方便一點，何必建立一個完全不同的模型呢。

引用:
3. 使用將xml標簽的屬性直接映射到對象屬性的方法造成tag對象是有狀態的，不得不通過丑陋的pool機制來解決性能問題。
而且性能問題直接限制了大量小標簽的使用。  

這是一個現實的困難，一個系統設計師必須考慮。

引用:
4. jsp tag是一種完全動態化的設計，大量可以在編譯期進行的優化都無法進行，基本上所有的運算都是在運行期發生，限制了性能的提高。  

我們的xml標簽技術是先編譯再運行的，加上無狀態設計，在性能上可以得到控制。我的朋友hotman_x是個C++和js高手，在他的強烈要求下，我們的xml標簽還增加了一個多次編譯的機制。

引用:

5. 雖然最近的版本已經支持xml格式，但對于xslt等的集成很不到位，例如現在無法使用xslt對jsp文件進行界面布局。

最簡單的
<web:template src="test.tpl" xslt="layout.xslt" />
<web:mytag xdecorator="face.xslt">
...
</web:mytag>

引用:
6. jsp tag要求使用自定義標簽名，而無法對已經存在的html標簽進行enhance, 造成無法方便的在可視化編輯器中進行編輯。  

Tapestry就認為它比較好。我們的xml標簽機制也支持屬性擴展。

引用:
7. EL表達式竟然不支持調用對象函數

很多人因此覺得OGNL比較好。我們的機制中是對EL做了一定的增強。我不喜歡OGNL, 過于復雜了。