標籤庫完成複雜的幕後處理功能的JSP樣本

       JSTL標籤是SUN帶頭與apache社區合作的產品，可惜從一出現就已經是一個過時的技術。SUN的軟體架構師似乎缺乏從顧客角度考慮技術取向的能力，與微軟相比差之千裡。就標籤技術而言，它的目的是令菜鳥中的菜鳥變得可以寫JSP，還是令一般程式員寫JSP顯得更方便，更好管理？顯然，SUN的那位笨蛋架構師沒有想明白這個道理（越是看得多它的文檔介始，越是覺得那個傢伙是個大笨蛋)，把SUN數千名天才工程師的才智白白浪費了。

　　所有人都已經知道，JSP出現的目的就是為了讓程式員更方便地寫簡單的servlet,複雜的多功能的servlet是不容易用JSP實現的。而JSP希望讓菜鳥寫java動態網頁面的目的並沒有達到，這條，還不如ASP/PHP。在JSP中散布底層商務邏輯既不便於對象組織，也不但於代碼管理，非常低效。這是發展出javaBean和標籤技術的原因；而JSTL呢，它的基本客戶邏輯竟然是為了協助使用者更方便地把底層代碼散布在JSP上！？包括資料庫連接？！所以這東西是一個新的技術實現落後目標的產品，面對市場需求整整慢了一拍。

唯一有點價值的是它的迴圈邏輯，這條還是很有用的。只不過能夠實現的不止它一個，struts.logic標籤就是很好用的一種，而且不用指向http:/sun.xxxx/core什麼的，事實上JSTL能夠提供的struts:logic也能夠提供。實際上struts幾個標籤庫中也就logi,有點價值，bean也可以，其他的html是純粹和FormBean為核心的MVC設想架構提供的。即使這樣，就實用性而言，strutslib仍比sun實用得多。

　　struts標籤庫不能很好地面向資料對象，這是它的不足，hanva標籤就是為了補充這個不足。結合struts的logic庫，使用hanva標籤可以達到在jsp中聲明和接收變數，可以實現多種邏輯，可以直接從底層獲得持久性非持外性的資料對象，處理並輸出——一個程式大致也就只有這些東西做的。特殊的東西再特殊處理，直接完全使用標籤調用下層服務daemon程式完成絕大部分功能，已經可以做到了。

　　下面的論壇樣本刪除程式是這樣的一個功能，可以處理任何的實現了hanvaDAO介面規範的表資料的刪除，包括對其相關資料記錄的同步處理。它接收一個物件類型(ent)，及ID，判斷這個對象（行記錄）是否存在，然後判斷它的sourceid和id是否一致（是主貼還是跟貼），如果是主貼，就把它的從貼一起刪除，否則就只刪除當前貼，然後返回原來調用的一頁，如果出錯，就轉向到errors.jsp頁，顯示出錯資訊。

<entity:present ent="${param.ent}" oid="${param.oid}" id="thent" nexto="${header.referer}">
   <%--如果記錄存在就繼承內嵌邏輯，把該記錄定為ident名--%>
   <%--判斷sourcid與id是否一致--%>
  <logic:equal name="thent" value="${thent.sourceid}" property="id">
<%--取所有主從貼，集合定名為theobjs--%>
   <entity:entities ent="${param.ent}" id="theobjs" qstr="sourceid=${sourceid}">
<%--迭代集合內容，單個取名為theobj--%>
    <logic:iterate id="theobj" name="theobjs">
<%--刪除該對象--%>
     <cmd:delete ent="${param.ent}" target="${theobj}"/>
    </logic:iterate>
   </entity:entities>
  </logic:equal>
  <logic:notEqual name="thent" value="${thent.sourceid}" property="id">
<%--單個從貼，清除該對象--%>
   <cmd:delete ent="${param.ent}" target="${thent}"/>
  </logic:notEqual>
 </entity:present>

　　標籤結束，根據nexto轉向到調用者，這樣段小代碼實際上就扮演了一個MVC中的c角色。如果需要輸出斷點，可以調用hanva:log 把即時內容輸出到log日誌中。一個比較複雜的功能就此完成了。全程實際上只是進行了一次或兩次資料庫的訪問，如果是多個從貼，需要獲得它的串，這是可能的第二次。注意<entity:entities>標籤，它輸入一個條件，也可以輸入fields選項，得到一個ArrayList串（沒有同步要求就不用Vector），如果不是為了翻頁，它可以代替hanva:list，使用上也更方便，沒有需要先設定一個dao.list對象。

　　我認為這才是標籤技術的真正用法：協助程式員在介面清晰明確地調用背景處理常式，即食麵向對象的商務邏輯的建立，方便隱藏非表達層的邏輯;而不是變成把頁面搞得更複雜，堆上更多難懂代碼的又一套新方法。

　　相對而言，tags檔案標籤技術顯得更現實一點。如同jsp是方便菜鳥（仍是程式員）寫簡單的servlet一樣，tags標籤檔案是方便看到Class就發抖的菜鳥象寫jspjavalet一樣寫標籤；顯然，是最簡單的SimpleTagSupport的變種，只有它才有一個體內容。也同樣，充分利用Class類結構的編碼技術在這裡沒有辦法實現。

　　JSP開發社團看來熱衷於在局部別具一格地提供一些局部方便性措施，卻常常忽略了客戶更大的一個要求：在項目開發中儘可能採用單一的標準的範式完成所有程式。多使用一種小技術模式在局部方便了，全域來說卻是多管理一種一種技術，或者說程式員要多學一種只在局部有效技術。這個邏輯錯誤從J2EE開始就伴隨著SUNJAVA的技術發展，看來是它的不治之症。在筆者看來，與其多搞小動作，不如在核心一鑽到底，而小範圍內的方便措施，還是有有能力的客戶去實現為佳。拙劣地模仿微軟去拍落後（也是非主流的客戶）的馬屁，將是SUN公司技術上最終失敗的原因。