每個(gè)web應用開(kāi)發(fā)者一定組織視圖組件，例如 頁(yè)首，正文體和頁(yè)尾。 有許多技術(shù)可以組織這些組件, 但每個(gè)都有優(yōu)缺點(diǎn)。這篇文章包括了7個(gè)可用的解決方案并讓你了解 Tiles框架和Struts框架的靈活性。從一個(gè)簡(jiǎn)單的說(shuō)明組織視圖組件的例子開(kāi)始,然后使用 JSP內建的機制,像include, 徹底地解決問(wèn)題。繼續看其他的使用Tiles框架的替換方案，然后學(xué)會(huì )平衡Tiles框架和Struts框架的協(xié)作。 (2,000個(gè)字;2002 年1月 4 日)
在Web應用軟件開(kāi)發(fā)中，一般用戶(hù)界面負責站點(diǎn)的外觀(guān)感覺(jué)，它可以讓人產(chǎn)生真切的感受。通過(guò)界面的展現，來(lái)展示應用程序功能和導航?；赟ervlet和JSP技術(shù)實(shí)現用戶(hù)界面時(shí)，當HTML頁(yè)面被轉換為servlets和JSPs時(shí),UI開(kāi)發(fā)人員必須識別哪些是公共的普通HTML頁(yè)面，哪些是JSP頁(yè)面組件，如標題、頁(yè)腳，主體，菜單和搜索等。這篇文章提供了多種有效的解決方案來(lái)組織HTML和JSP視圖組件。每個(gè)方案都使用了特定的標準，像頁(yè)數、編碼重復和布局控制等。
為了探究模板和布局方案，我們使用Tiles 框架.Tiles 框架的視圖組件叫做tiles?？蚣?nbsp;使用XML配置文件來(lái)組織這些tiles.框架不僅能讓你再次使用tiles,而且還可以對他們進(jìn)行設計組織。
為了探尋更強大和靈活的方案，我們研究Tiles框架和Struts 框架之間的協(xié)作。Struts是一個(gè)使用流行的MVC或者M(jìn)odel 2結構模式的用于開(kāi)發(fā)web 應用軟件的開(kāi)源框架.Struts 有著(zhù)強大標簽庫，Tile框架的標簽庫加入使其更加完善。
評價(jià)標準
評價(jià)每個(gè)方案有如下標準。標準是兼容的。對于特定的情況和特殊的應用，必須經(jīng)常均衡每個(gè)方案中這些因素的優(yōu)勢與缺陷。
頁(yè)數（Page number）
方案必須盡量使HTML and JSP的頁(yè)數減到最小。因為頁(yè)數增加，開(kāi)發(fā)、管理、維護一個(gè)應用程序的復雜性將會(huì )急劇增加。
代碼重復（Code repetiton）
在大多數情況下，重復是不好的。HTML and JSP編碼越是重復，開(kāi)發(fā)和維護應用程序就越困難。一個(gè)簡(jiǎn)單變化可能在許多不同頁(yè)面上導致一連串不可預期結果的改變。具體和實(shí)際的獲得重新使用的方式應避免編碼重復。
布局控制（Layout comtrol）
盡管編碼重復是不好的，但是布局邏輯和編碼重復的會(huì )更糟。在幾個(gè)JSPs中的擴展視圖組件結構的邏輯和行為可以是一個(gè)解決災難的方法。獲得模板的設計邏輯的重復使用是一種比僅僅重復使用視圖組件更好的形式。因此，你可以通過(guò)有效的布局控制達到一個(gè)更高的重復使用的水平。
耦合（Coupling）
耦合是個(gè)實(shí)體間的兼容性的一個(gè)度。軟件工程師被重復教育要使不相干的類(lèi)、包等等之間的耦合減到最小。我們可以對視圖組件應用相同的原理。盡管從一個(gè)使用者角度講視圖組件之間是有區別的，但在JSP執行中，組建可能被雜亂的連接。一種解決方案使必須減少不相干視圖組件之間的耦合.
復雜性（Complexity）
復雜性導致了更多的開(kāi)發(fā)和維護費用，也使得更多的復雜方案不合適。當你增加更多的部分時(shí)，復雜性同時(shí)也在增加，這將使原本看起來(lái)簡(jiǎn)單的和無(wú)害的東西很快轉變?yōu)榇蠡靵y。
解決方案
我將使用基本的JSPs例子。通過(guò)像header ,footer這樣的普通的視圖組件來(lái)評價(jià)一些方案。我將按增加復雜性的順序給出這些方案，然后相對于評價(jià)標準詳細的評價(jià)每一個(gè)。
方案1：基本的JSP
假如a.jsp如下:
<html> <body> Header<p> a‘s body...<p> Footer<p> </body> </html> |
假如b.jsp如下:
<html> <body> Header<p> b‘s body...<p> Footer<p> </body> </html> |
在許多情況，開(kāi)發(fā)者從UI類(lèi)中直接獲取編碼，并根據需要直接將他轉換成JSP代碼。如上所示，每個(gè)JSP有重復的HEADER 和FOOTER。方案1是不合需求的，原因是HEADER和 FOOTER視圖組件改變，因每頁(yè)都為所放置的組件負責，所以需要在所有相關(guān)頁(yè)上改變。簡(jiǎn)單的方案1缺乏遠見(jiàn)。有著(zhù)如此多HTML和JSP 代碼重復，我們雖然減少了頁(yè)的數量，但是需要一個(gè)很大的維護費用。就像前面所解釋的，不同的視圖組件間有著(zhù)很大的耦合 ,所以這是不合需要的。
方案2：JSP include
假如 a.jsp如下:
<html> <body> <%-- include header --%> <jsp:include page="/header.jsp" /> a‘s body... <p> <%-- include footer --%> <jsp:include page="/footer.jsp" /> </body> </html> |
假如b.jsp如下:
html> <body> <%-- include header --%> <jsp:include page="/header.jsp" /> b‘s body... <p> <%-- include footer --%> <jsp:include page="/footer.jsp" /> </body> </html> 注意到普通的諸如header和footer這樣的視圖組件，使用JSP 的include結構使其分開(kāi)來(lái)了。 假如 header.jsp如下: Header <p> 假如footer.jsp如下: Footer <p> |
方案2很好的處理了方案1中的一些重要的缺陷。你僅需要改變一次通用的視圖組件。因此，這個(gè)方案在很大程度上消除了HTML和JSP CODE重復，尤其是提高了應用程序的可維護性。他增加了一些頁(yè)數，但他徹底的減少了普通視圖組件和其他頁(yè)之間的輕微的耦合.在復雜度上，這個(gè)方案可以很簡(jiǎn)單和容易的使用在現有應用程序中。但是，他有一個(gè)最主要的缺點(diǎn)：如果你改變了如何組織和哪里放置視圖組件（例如，改變組件的布局），你必須更新每一頁(yè)--導致了額外的、禁止的改變。方案2成功的使視圖組件可以重復使用，但是不能重復使用布局和模板邏輯。
方案3 Tiles insert
假如a.jsp如下： <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert page="/header.jsp" flush="true"/> a‘s body... <p> <%-- include footer --%> <tiles:insert page="/footer.jsp" flush="true"/> </body> </html> 假如b.jsp如下： <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert page="/header.jsp" flush="true"/> b‘s body... <p> <%-- include footer --%> <tiles:insert page="/footer.jsp" flush="true"/> </body> </html> |
方案3 使用Tiles insert 機制來(lái)代替JSP include 結構。使用Tiles insert 標簽,你可將視圖組件放置到恰當的位置。在其它所以方面，方案精確的鏡像了JSP include方案（方案2），包括了優(yōu)點(diǎn)和缺點(diǎn)。
方案4：Spiltting bodies
假如 a.jsp如下: <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert page="/header.jsp" flush="true"/> <%-- include body --%> <tiles:insert page="aBody.jsp" flush="true"/> <%-- include footer --%> <tiles:insert page="/footer.jsp" flush="true"/> </body> </html> 假如b.jsp如下: <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert page="/header.jsp" flush="true"/> <%-- include body --%> <tiles:insert page="bBody.jsp" flush="true"/> <%-- include footer --%> <tiles:insert page="/footer.jsp" flush="true"/> </body> </html> 方案4與Tiles insert方案有些小的不同。方案4將核心主體分隔成幾個(gè)單獨頁(yè)面，如aBody.jsp and aBody.jsp. 假如 aBody.jsp如下: a‘s body... <p> 假如bBody.jsp如下: b‘s body... <p> |
方案4 的優(yōu)點(diǎn)：他限制了body轉變到各個(gè)頁(yè)。同時(shí)，在其他地方他也讓你能重復使用bodies,消除了重復的需要。因此，這個(gè)方案更加減少了通用視圖組件于其他應用軟件組件間的coupling 。產(chǎn)生和管理每個(gè)body組件引進(jìn)了一個(gè)附加的復雜度。因為用其它的方案的話(huà)，每頁(yè)依舊是他自己的布局。因此，沒(méi)有過(guò)多的布局法則或模式。
方案5：Templating tiles
使用Tiles的框架特性，我們可將下面的布局作為模板定義（來(lái)自下面所示的layout.jsp文件）。因為這個(gè)布局，所以用Tiles tag來(lái)插入標識符代替實(shí)際的視圖組件。因此，對于所有組件而言，這頁(yè)定義了一個(gè)可重復使用的布局：
<%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert attribute="header"/> <%-- include body --%> <tiles:insert attribute="body"/> <%-- include footer --%> <tiles:insert attribute="footer"/> </body> </html> 其它的內容頁(yè)，像a.jsp and b.jsp使用如上布局來(lái)放置組件。在實(shí)際的頁(yè)面里，使用Tiles insert tag來(lái)插入布局。使用Tiles put tag可以為布局中特定的標識符指定實(shí)際的視圖組件。 假如a.jsp如下: <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %> <tiles:insert page="/layout.jsp" flush="true"> <tiles:put name="header" value="/header.jsp"/> <tiles:put name="body" value="/aBody.jsp"/> <tiles:put name="footer" value="/footer.jsp"/> </tiles:insert> 假如b.jsp如下: <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %> <tiles:insert page="/layout.jsp" flush="true"> <tiles:put name="header" value="/header.jsp"/> <tiles:put name="body" value="/bBody.jsp"/> <tiles:put name="footer" value="/footer.jsp"/> </tiles:insert> |
方案5最突出的優(yōu)勢是他封裝了布局原理圖或結構方式，徹底的減少了通用視圖組件和其他內容主體間的coupling。然而，他引入了其他布局頁(yè)面增加了復雜性。首先，理解與執行模塊就有困難。
方案6：Struts and Tiles
上面的layout.jsp布局頁(yè)面，包含了組織組件的HTML and JSP code.內容頁(yè)a.jsp and b.jsp不包含任何的HTML code;僅僅包括了Tiles tags來(lái)插入必需的組件。在一個(gè)XML文件中指定所有的內容頁(yè)面會(huì )好一點(diǎn)嗎？讓我們來(lái)tileDefinitions.xml文件，指定其頁(yè)面如下：
<?xml version="1.0" encoding="ISO-8859-1"?> <component-definitions> <definition name="aDef" path="/layout.jsp"> <put name="header" value="/header.jsp"/> <put name="footer" value="/footer.jsp"/> <put name="body" value="/aBody.jsp"/> </definition> <definition name="bDef" path="/layout.jsp"> <put name="header" value="/header.jsp"/> <put name="footer" value="/footer.jsp"/> <put name="body" value="/bBody.jsp"/> </definition> <definition name="cDef" path="/layout.jsp"> <put name="header" value="/header.jsp"/> <put name="footer" value="/footer.jsp"/> <put name="body" value="/cBody.jsp"/> </definition> </component-definitions> 方案6把定義放置在XML文件中，消除了就像a.jsp and b.jsp一樣的所有內容頁(yè)。因像a.jsp and b.jsp這樣的程序不再存在，我們怎樣請求他？更重要的是，如何在tileDefinitions.xml文件中請求定義？ Struts and Tiles強大和協(xié)作的整體可被挽回。除了常規的配置參數以外，我們在web.xml文件中作為另一個(gè)參數指定配置文件的地址。如下所示。指定參數definitions_config使Struts能找到并知道關(guān)于Tiles 的定義。 <!-- Standard Action Servlet Configuration (with debugging) --> <servlet> <servlet-name>action</servlet-name> <!-- <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> --> <servlet-class>org.apache.struts.tiles.ActionComponentServlet</servlet-class> <init-param> <param-name>definitions-config</param-name> <param-value>/WEB-INF/tileDefinitions.xml</param-value> </init-param> ... </servlet> 我們現在定義一個(gè)Struts action,他將返回一個(gè)成功的在配置文件中指定的定義。Struts action DoFirst 是一個(gè)不運行的行為，如下所示： package com.malani.struts.action; import org.apache.struts.action.*; import javax.servlet.http.*; public class DoFirst extends Action { public ActionForward perform( ActionMapping aMapping, ActionForm aForm, HttpServletRequest aRequest, HttpServletResponse aResponse ) { return aMapping.findForward("success"); } } 你不能使用直接來(lái)自瀏覽器的定義，但是 你可以使用來(lái)自Struts的就像實(shí)際程序一樣的一個(gè)。在struts-config.xml的文件中定義Struts actions如下： <action path="/a" type="com.malani.struts.action.DoFirst" > <forward name="success" path="aDef"/> </action> <action path="/b" type="com.malani.struts.action.DoFirst" > <forward name="success" path="bDef"/> </action> <action path="/c" type="com.malani.struts.action.DoFirst" > <forward name="success" path="cDef"/> </action> 現在通過(guò)分別請求a.do and b.do actions來(lái)返回所需的程序。 |
方案6的主要優(yōu)點(diǎn)是他把所有的定義都統一到一個(gè)XML配置文件里。減少內容頁(yè)很徹底的減少了總的頁(yè)數。通過(guò)引進(jìn)Struts,在另個(gè)方法上增加了復雜性。
方案7：Tiles inheritance
在定義配置文件中，可觀(guān)察到每頁(yè)定義看起來(lái)是一樣的。每個(gè)定義有三個(gè)組件，兩個(gè)被固定為header and footer.強大的Tiles特性使得定義間有了繼承性。因此，你可以定義一個(gè)基礎定義，讓原始定義從那個(gè)定義上繼承來(lái)。原始的定義必須僅支持他們的單一部分。下面顯示了帶有定義間繼承性的XML配置文件：
<?xml version="1.0" encoding="ISO-8859-1"?> <component-definitions> <definition name="baseDef" path="/layout.jsp"> <put name="header" value="/header.jsp"/> <put name="footer" value="/footer.jsp"/> <put name="body" value=""/> </definition> <definition name="aDef" extends="baseDef"> <put name="body" value="/aBody.jsp"/> </definition> <definition name="bDef" extends="baseDef"> <put name="body" value="/bBody.jsp"/> </definition> <definition name="cDef" extends="baseDef"> <put name="body" value="/cBody.jsp"/> </definition> </component-definitions> |
這個(gè)方案的優(yōu)勢是消除了配置文件理重復和多余的信息?？傊?，這個(gè)方案的優(yōu)點(diǎn)和缺點(diǎn)與Struts and Tiles方案的一樣。
方案總結
如下表格總結了各個(gè)方案的評價(jià)指標方面的內容。我鼓勵你增加其他的有創(chuàng )造性的方案，和其他重要的，像可延展性、可維護性、可操作性這樣的評價(jià)指標。
各種解決方案的每項評估指標：
表格表明每個(gè)方案的復雜度是逐漸上升的。同時(shí)他也表明當你增加復雜度時(shí)，減少了編碼復制，增加了設計控制的靈活性，減少了不相干視圖組件的Coupling.頁(yè)數最初是當視圖組件分開(kāi)時(shí)增加的，但當你在一個(gè)定義結構之中定義了更多頁(yè)的時(shí)候，合并會(huì )發(fā)生。
那個(gè)方案是最好的？
最好的方案是要依據你項目所需和你在開(kāi)發(fā)和維護一個(gè)web應用程序中的技能和知識?；镜姆桨柑?jiǎn)單；我并不推薦他，因為他不支持好的軟件工程師的實(shí)踐經(jīng)驗的思路。如果你的web應用程序是復雜的，模板給你提供了一個(gè)很好的布局控制。因此你可能想研究和使用一個(gè)像Tiles一樣的模板框架。如果你已經(jīng)使用了Struts，接著(zhù)你必須為一個(gè)強大的方案調節Tiles and Struts之間的協(xié)作。
Divine design
在這篇文章里，評價(jià)了不同的在HTML and JSPs中組織視圖組件的方案。同時(shí)也研究了Struts and Tiles框架之間的協(xié)作性。這些策略和方案可以幫助你做一個(gè)有關(guān)于你的web應用程序的設計和結構的決定。
對審閱這篇文章的Max Cooper, Stephen Ditlinger, Dru Jensen, Phillip Lindsay, Roshni Malani, Danny Trieu, and Clare Zhang致以最誠摯的謝意。
資源：
方案1-7源代碼：
Tiles框架：
