NFJS 2.2-Killer Web UIs: with Tiles and Site Mesh

Another one of David Geary's publicity for JSF. The main theme of the presentation; although Tiles and Site mesh are inverse of each other and are not liked by each other's folks, one can actually achieve more by using both of them in an application. The talk was divided into an introduction to DRY (agile design pattern), an intro to composer and decorator design patterns, capabilities of both Tiles and Site mesh, their differences and how to use them together. The talk was designed around a login page, and an account creation page demo and various functionalities achieved using both site mesh and tiles. It is hard to explain the workings in a few paragraphs and the best way to understand this stuff would be to look at the actual code of the demo from the presentation which is included in the Syposium CD. Please feel free to ask if you would like to have a look, and I can borrow it to you :) I will try my best to bring up all the important points discussed in the talk.

The contents of a web-app can be either displayed by using all in one single jsp (horrible because it is repeating everything), using jsp includes (both static and dynamic) or by using Tiles or/and Site-mesh. Header, Menu, Content Layout is very typical in common web apps and Tiles and Site-mesh both help to encapsulate both the content and layout.

The idea of tiles was due to David's 'bath tub' thought of the Layout manager on the server side in Java and he created the template library for the server side which was contributed to Struts after his meeting with Craig McClanahan. Dumoulin took this template library and extented its components which gave birth to the modern day Tiles library. So currently Tiles is a Struts sub-project although a stand alone Tiles version is also available... Not sure what will happen to Tiles after the death of Struts, will it be a part of Shale (atleast Shale helps to code with Tiles). Tiles consist of a Servlet, JSP tag library, tile Parser (essentially an XML parser) and a Tile generation factory. To sum up, Tiles is all about Encapsulating and Reusing Layout and Content.

The main use of tiles include the ability of making content reuseable by avoiding hardcoding which is according to the Agile Programming principles. Tiles provide the capability to implement one single layout, define a tile and then plugin the same tile in different locations. Besides, tiles can be nested inside each other using the composite design pattern. Tiles can be extended much like inheritence and we can inherit the parent tile's layout and attributes. Different tiles can also be restricted to user roles and tile controllers can be used to dynamically create the tiles instead of staticly defining them in an XML file.

A few questions about Tiles.. how to test tiles. Tiles don't have any test cases but if implemented with Struts Tiles, can be tested with Struts test. In the case of nesting tiles, attributes are only visible for the current tile and not to the nested tile, but they can be exported to the session and the nested tiles can see them.

Sitemesh is a SourceForge project. It consists of Servlet filters, JSP tag library and page parsers. Just like Tiles, it uses the server side layout managers. The main difference between tiles and sitemesh is the design patterns that are used to implement the discrete pieces. Tiles 'Composes' the discrete pieces whereas Sitemesh 'decorates' them. I think it will be a good idea here to explain some stuff about composite and decorator patterns here. A composite lets clients to treat individual objects and composition of objects uniformly whereas a decorator attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. So in the case of sitemesh, a page comes in and sitemesh puts a wrapper or a decoration around it (adds additional stuff). Sitemesh is easy to implement. Basically, we need to implement the decorator class. Define the decorator in an XML file and include the content and apply decorators recursively.

Various pros and cons of using Tiles:
+ We can compose and display a page at run time. Allows for parametrized layout/inheritence. The controllers can be used for dynamic composition
+ Works well with JSF (a JSF selling point :))
+ Works well with JSPs
- Marginal Support for decoration.
- Much more verbose than sitemesh. Can be experienced by visualizing the config files for both.
Various pros and cons of using SiteMesh:
+ Very good solution using decoration. Allows to tie decoration to URLs and even a group of files having a specific pattern. Very powerful aspect as with only a few lines of code a decoration can be applied to a whole set of JSPs. It also enables us to recursively apply decorations.
+ Sitemesh works well with existing HTML websites. So if we have a website with a set of static pages and we want to move to Java space
+ Works well with JSPs
- Sitemesh does not provide the capability to parametrize layout content. It does not have the same level of indirection so we end up hardcoding a bunch of stuff.
- Sitemesh does not work well with JSF. (DEFINITELY Not a pick by David :-) So it is a real bummer.. This is because Decorators can not have JSF tags and doing so just displays a blank page.

So instead of fighting to pick and choose between Tiles and Sitemesh, it is a good idea to be able to and prefer to use both. ' A BOTH PERSON'... David showed a demo that was a pretty good use case for a common union of Tiles and Sitemesh. The idea is summarized as follows..
Use Tiles to compose for reusing layouts (tiles prvides sophisticated composition) and use Sitemesh on the tiles generated page for decorating (e.g., print page links, error messages etc.)

What does the future hold for Tiles... Adding AJAX (the Buzzword) to the tiles so that they wont have to refresh the page all at once.