Over the years, I have designed and implemented two popular web layout technologies – Struts Tiles and SiteMesh. In the beginning, I was very new to layout technology and had very little knowledge. Once my project architect asked me to use Struts Tiles for JSPs. I was wondering why to use such technology if everything can be done in a single JSP or separate the components of single JSP into bits & pieces and finally include it in main JSP page. After completing & supporting application for some time, it struck my mind “real benefits” using layout technology.
Every web application has common look and feel & has common content to be displayed such as header, footer, side menu, copyright footer etc and these pages appear in almost all functional pages. Layout technology makes managing & maintaining these common resources easier with minimum effort & less impact.
From my experience, I see lot of real benefits using layout technology.
Merits:
a) Separate content from layout
Layout allows you to decouple content from the structure. Layout deals with how content should be presented & content deals with ‘what gets displayed’. So, essentially we are NOT mixing functional pages with commonly included pages. This makes life easier during application maintenance because you know where to concentrate & isolate the problem.
b) Allows to structure or divide the page logically ( ex: header should come on top, footer on bottom etc)
Layout provides more control in designing how content should be displayed.
No doubt, logical division of components can be done using JSPs, but there is no central control or involves more time if modifications are to be done. Imagine, if you want to change the structure say move the copy right footer above general footer, then you end up making changes to all your JSPs which takes away your time.
c) Reuse the layouts across site
Once layouts are designed & coded, they can be reused across sites for functional JSPs.
d) Single or central place for modification
Instead of including JSPs, if we use layout and include pages dynamically , duplication in functional pages can be avoided. So, the catch is – if you include individual JSPs in your functional JSPs, it takes effort to modify & re-compile as you are touching many JSPs. Instead, if you have a single layout & include your JSPs , there is only one place where you can modify & changes are propagated across all functional JSPs within no time. Also, if you want to add any conditional statements around your included JSPs, it can be very well done in single layout rather than touching all JSPs.
BIG question? Which layout technology suits my application?
Well, from my experience Tiles is good but after working with SiteMesh, i see lot of plus points using SiteMesh over Tiles.
Tiles is an implementation of ‘composite’ pattern where is SiteMesh is a ‘decorator’ pattern implementation.
One issue with Tiles is - for each JSP forward, you need to configure ‘Path’ in struts.xml under action mapping & end up repeating ‘path’ for all JSP forwards even though your layout is same. For whatever reason, if you change the path name, you will have to change in all places. So, your JSP is tightly tied to path and all JSPs are tightly coupled to tiles layout. If you want to change the layout technology, you have significant changes in the configuration.
On the contrary, if you use SiteMesh, there is no JSP tie up with layout at least in struts.xml. You can create a single decorator & apply this decorator for a set of JSPs. If you want to use different decorator, just remove the JSP entry from decorator.xml and add it to other one. So, there is ‘loose coupling’ & switching to newer layout technology is much much easier.
Overall, maintenance of application is easier in SiteMesh than in tiles since SiteMesh has fewer configurations & not tied to any view technology. But, Tiles has some features such as decorating error pages like 404,500 etc which is not there in SiteMesh.
I have used SiteMesh. It’s Simple Yet Powerful !!!.
Wednesday, January 21, 2009
Subscribe to:
Post Comments (Atom)

No comments:
Post a Comment