|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Typically during Web application development, the user interface (UI) group creates the site's look and feel. Based on that look and feel, the group creates HTML pages that represent the application's functionality and navigation. With a servlets and JavaServer Pages (JSPs)-based implementation, where HTML pages are converted into servlets and JSPs, UI developers identify common HTML and JSP view components, such as header, footer, body, menu, and search. This article presents various solutions to effectively and efficiently organize HTML and JSP view components. I evaluate each solution using specific criteria, such as page number, code repetition, and layout control.
To explore templating and layout solutions, we will use the Tiles framework. The Tiles framework's view components are known as tiles. The framework uses an XML configuration file to organize those tiles. This framework not only enables you to reuse tiles, but also the layouts that organize them.
To explore the more powerful and flexible solutions, we will investigate the synergy between the Tiles and Struts frameworks. Struts is an open source framework for developing Web applications using the popular Model-View-Controller (MVC) or Model 2 architectural pattern. Struts comes with a large set of reusable tags for which the Tiles tag library makes an excellent enhancement.
I will evaluate each solution based on the criteria below. The criteria are not mutually exclusive. For a specific situation and particular application, you must always balance between the strengths and weaknesses of each solution with respect to these factors.
a.jsp:
<html> <body> Header <p> a's body... <p> Footer <p> </body> </html>
Consider the following JSP for b.jsp:
<html> <body> Header <p> b's body... <p> Footer <p> </body> </html>
In many cases, the developers obtain the code from the UI group and literally convert it into a JSP as necessary. As shown above, each JSP has a duplicate header and footer. Solution 1 is undesirable because changes in common view components, like header and footer, require changes in all relevant pages, as each page is responsible for laying out the view components. This simple solution lacks foresight. With so much HTML and JSP code duplication, we minimize the number of pages but at a heavy maintenance cost. There is strong coupling between the different view components, which, as I explained earlier, is undesirable.
a.jsp:
<html> <body> <%-- include header --%> <jsp:include page="/header.jsp" /> a's body... <p> <%-- include footer --%> <jsp:include page="/footer.jsp" /> </body> </html>
Consider the following JSP for b.jsp:
<html> <body> <%-- include header --%> <jsp:include page="/header.jsp" /> b's body... <p> <%-- include footer --%> <jsp:include page="/footer.jsp" /> </body> </html>
Note that common view components, like header and footer, are split up using the JSP include mechanism.
Consider this header.jsp:
Header <p>
Consider this footer.jsp:
Footer <p>
Solution 2 nicely addresses some of Solution 1's major shortcomings. You only need to change common view components once. Hence, this solution greatly eliminates HTML and JSP code repetition, significantly improving application maintainability. It increases the page number a bit, but drastically reduces the tight coupling between common view components and other pages. On the complexity scale, this solution is simple and readily implemented on many real-world applications. However, it has one major drawback: if you change how and where you organize the view components (i.e., by changing the component layout), then you would need to update every page -- resulting in an expensive and prohibitive change. Solution 2 achieves view component reuse, but does not achieve the reuse of layout and templating logic.
Consider this JSP for 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>
Consider this JSP for 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>
Instead of using the JSP include mechanism, Solution 3 uses the Tiles insert mechanism. Using the Tiles insert tag, you include the view components in the appropriate positions. In all other aspects, the solution mirrors the JSP include solution (Solution 2) exactly, with the same advantages and disadvantages.