應該如何使用標簽技術?使用EL,logic和hanva標簽庫完成複雜的後台處理功能的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頁,顯示出錯信息。
<%--如果記錄存在就繼承內嵌邏輯,把該記錄定?ident名--%>
<%--判斷sourcid與id是否一致--%>
<%--取所有主從貼,集合定名?theobjs--%>
<%--?代集合內容,單個取名?theobj--%>
<%--刪除該對象--%>
<%--單個從貼,清除該對象--%>
標簽結束,根據nexto轉向到調用者,這樣段小代碼實際上就扮演了一個MVC中的c角色。如果需要輸出斷點,可以調用hanva:log 把實時內容輸出到log日志中。一個比較複雜的功能就此完成了。全程實際上只是進行了一次或兩次數據庫的訪問,如果是多個從貼,需要獲得它的串,這是可能 的第二次。注意
我認?這才是標簽技術的真正用法:幫助程序員在界面清晰明確地調用後台的處理程序,方便面向對象的業務邏輯的建立,方便隱藏非表達層的邏輯;而不是變成把頁面搞得更複雜,堆上更多難懂代碼的又一套新方法。
相對而言,tags文件標簽技術顯得更現實一點。如同jsp是方便菜鳥(仍是程序員)寫簡單的servlet一樣,tags標簽文件是方便看到 Class就發抖的菜鳥象寫jspjavalet一樣寫標簽;顯然,是最簡單的SimpleTagSupport的變種,只有它才有一個體內容。也同樣, 充分利用Class類結構的編碼技術在這?沒有辦法實現。
JSP開發社團看來熱衷于在局部別具一格地提供一些局部方便性措施,卻常常忽略了客戶更大的一個要求:在項目開發中盡可能采用單一的標准的範式完成 所有程序。多使用一種小技術模式在局部方便了,全局來說卻是多管理一種一種技術,或者說程序員要多學一種只在局部有效的技術。這個邏輯錯誤從J2EE開始 就伴隨著SUNJAVA的技術發展,看來是它的不治之症。在筆者看來,與其多搞小動作,不如在核心一鑽到底,而小範圍內的方便措施,還是有有能力的客戶去 實現?佳。拙劣地模仿微軟去拍落後(也是非主流的客戶)的馬屁,將是SUN公司技術上最終失敗的原因。
http://blog.csdn.net/zwwwxy/archive/2005/04/24/360540.aspx
http://zwwwxy.blogchina.com/1431465.html
0 Comments:
Post a Comment
<< Home