A story of getting the View layer up and running quickly in Spring, using Tiles with wildcards, fallbacks, and definition includes, to use the Composite pattern and Convention over Configuration providing a minimal ongoing xml changes.
Summary
From the architect’s perspective you see Apache Tiles as rare exotic Italian marble sheets laid out exquisitely, while the same architect will see SiteMesh as the steel wiring stuck inside the concrete slab. The beauty of the tiles is always admired and a key component in creating an eye-catching surrounding.

Background
At FINN.no we were redesigning our control and view layers. We, being the architectural team of six, had already decided on Spring-Web as a framework for the control layer due to its flexibility and a design for us providing better, simpler, migration path. For the front end we were a little unclear. In a department of ~60 developers we knew that the popular vote would lead us towards SiteMesh. And we knew why for practical purposes sitemesh gives the front end developer more flexibility and less xml editing. But we knew sitemesh has some serious shortcomings…
SiteMesh shortcomings:
- from a design perspective the Decorator pattern doesn’t combine with MVC as elegantly as the Composite pattern does
- requires to hold all possible html for a request in buffer requiring large amounts of memory
- unable to flush the response before the response is complete
- requires more overall processing due to the processing of all the potentially included fragments
- does not guaranteed thread safety
- does not provide any structure or organisation amongst jsps, making refactorings and other tricks awkward
One of the alternatives we looked at was Apache Tiles. It follows the Composite Pattern, but within that allows one to take advantage of the Decorator pattern using a ViewPreparer. This meant it provided by default what we considered a superior design but if necessary could also do what SiteMesh was good at. It already had integration with Spring, and the way it worked it meant that once the Spring-Web controller code was executed, the Spring’s view resolver would pass the ball onto Tiles letting it do the rest. This gave us a clear MVC separation and an encapsulation ensuring single thread safety within the view domain.
Yet the most valuable benefit Tiles was going to offer wasn’t realised until we started experimenting a little more…
In step3, The given sample code is wrong. It would not compile as all the methods have the same name, though the intent is clear by looking at the @RequestMapping annotation.
Excellent article!! I would definitely use this in my next project
EDIT: Thanks for pointing out the error. It has been corrected. ~mck
How did you override createPatternDefinitionResolver(Class) in SpringTilesContainerFactory? According to http://tiles.apache.org/framework/tutorial/advanced/wildcard.html that must be done before REGEXP: definition names will be understood by Tiles.
I could just subclass BasicTilesContainerFactory instead, but I assume the stuff in SpringTilesContainerFactory is required.
I could make another class, then copy-paste SpringTilesContainerFactory and add the extra method, but that doesn’t seem very nice.
I could make another class, then use declare parents in a privileged aspect to force in that private class as the superclass, but that doesn’t seem very nice, either.
Thanks for the great article!
Joe,
FinnTilesContainerFactory.java extends BasicTilesContainerFactory.
The code for it is: