JSTL標簽是SUN帶頭與apache社區合作的產品可惜從一出現就已經是一個過時的技術SUN的軟件架構師似乎缺乏從顧客角度考慮技術取向的能力與微軟相比差之千裡就標簽技術而言它的目的是令菜鳥中的菜鳥變得可以寫JSP還是令一般程序員寫JSP顯得更方便更好管理？顯然SUN的那位笨蛋架構師沒有想明白這個道理（越是看得多它的文檔介始越是覺得那個家伙是個大笨蛋)把SUN數千名天才工程師的才智白白浪費了
所有人都已經知道JSP出現的目的就是為了讓程序員更方便地寫簡單的servlet復雜的多功能的servlet是不容易用JSP實現的而JSP希望讓菜鳥寫java動態頁面的目的並沒有達到這條還不如ASP/PHP在JSP中散布底層業務邏輯既不便於對象組織也不但於代碼管理非常低效這是發展出javaBean和標簽技術的原因而JSTL呢它的基本客戶邏輯竟然是為了幫助使用者更方便地把底層代碼散布在JSP上！？包括數據庫連接？！所以這東西是一個新的技術實現落後目標的產品面對市場需求整整慢了一拍
唯一有點價值的是它的循環邏輯這條還是很有用的只不過能夠實現的不止它一個strutslogic標簽就是很好用的一種而且不用指向什麼的事實上JSTL能夠提供的struts:logic也能夠提供實際上struts幾個標簽庫中也就logi有點價值bean也可以其他的html是純粹和FormBean為核心的MVC設想框架提供的即使這樣就實用性而言strutslib仍比sun實用得多
struts標簽庫不能很好地面向數據對象這是它的不足hanva標簽就是為了補充這個不足結合struts的logic庫使用hanva標簽可以達到在jsp中聲明和接收變量可以實現多種邏輯可以直接從底層獲得持久性非持外性的數據對象處理並輸出——一個程序大致也就只有這些東西做的特殊的東西再特殊處理直接完全使用標簽調用下層服務daemon程序完成絕大部分功能已經可以做到了
下面的論壇示例刪除程序是這樣的一個功能可以處理任何的實現了hanvaDAO接口規范的表數據的刪除包括對其相關數據記錄的同步處理它接收一個對象類型(ent)及ID判斷這個對象（行記錄）是否存在然後判斷它的sourceid和id是否一致（是主貼還是跟貼）如果是主貼就把它的從貼一起刪除否則就只刪除當前貼然後返回原來調用的一頁如果出錯就轉向到errorsjsp頁顯示出錯信息
<entity:present ent="${parament}" oid="${paramoid}" id="thent" nexto="${headerreferer}">
<%如果記錄存在就繼承內嵌邏輯把該記錄定為ident名%>
<%判斷sourcid與id是否一致%>
<logic:equal name="thent" value="${thentsourceid}" property="id">
<%取所有主從貼集合定名為theobjs%>
<entity:entities ent="${parament}" id="theobjs" qstr="sourceid=${sourceid}">
<%迭代集合內容單個取名為theobj%>
<logic:iterate id="theobj" name="theobjs">
<%刪除該對象%>
<cmd:delete ent="${parament}" target="${theobj}"/>
</logic:iterate>
</entity:entities>
</logic:equal>
<logic:notEqual name="thent" value="${thentsourceid}" property="id">
<%單個從貼清除該對象%>
<cmd:delete ent="${parament}" target="${thent}"/>
</logic:notEqual>
</entity:present>
標簽結束根據nexto轉向到調用者這樣段小代碼實際上就扮演了一個MVC中的c角色如果需要輸出斷點可以調用hanva:log 把實時內容輸出到log日志中一個比較復雜的功能就此完成了全程實際上只是進行了一次或兩次數據庫的訪問如果是多個從貼需要獲得它的串這是可能的第二次注意<entity:entities>標簽它輸入一個條件也可以輸入fields選項得到一個ArrayList串（沒有同步要求就不用Vector）如果不是為了翻頁它可以代替hanva:list使用上也更方便沒有需要先設定一個daolist對象
我認為這才是標簽技術的真正用法幫助程序員在界面清晰明確地調用後台的處理程序方便面向對象的業務邏輯的建立方便隱藏非表達層的邏輯;而不是變成把頁面搞得更復雜堆上更多難懂代碼的又一套新方法
相對而言tags文件標簽技術顯得更現實一點如同jsp是方便菜鳥（仍是程序員）寫簡單的servlet一樣tags標簽文件是方便看到Class就發抖的菜鳥象寫jspjavalet一樣寫標簽顯然是最簡單的SimpleTagSupport的變種只有它才有一個體內容也同樣充分利用Class類結構的編碼技術在這裡沒有辦法實現
JSP開發社團看來熱衷於在局部別具一格地提供一些局部方便性措施卻常常忽略了客戶更大的一個要求在項目開發中盡可能采用單一的標准的范式完成所有程序多使用一種小技術模式在局部方便了全局來說卻是多管理一種一種技術或者說程序員要多學一種只在局部有效的技術這個邏輯錯誤從JEE開始就伴隨著SUNJAVA的技術發展看來是它的不治之症在筆者看來與其多搞小動作不如在核心一鑽到底而小范圍內的方便措施還是有有能力的客戶去實現為佳拙劣地模仿微軟去拍落後（也是非主流的客戶）的馬屁將是SUN公司技術上最終失敗的原因
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/20163.html
