Compare Sitemesh Vs Tiles, an overview
If you haven’t heard about the layout framework, Sitemesh which is based on the decorator pattern, you’re missing something in your webapp. Here’s a quick overview of both the Frameworks and obviously Sitemesh favors over Struts Tiles in a lot of ways.
The Pros:
Compatibility: Works virtually with all web frameworks while Tiles has limited compatibility (more or less Struts Centric)
Maintainance: Easier to setup, maintain, decorate pages, understand and use
Filters based: Sitemesh is based on Servlet Fitlers instead of JSP includes which means it intercepts right at the request level.
Configuration: Sitemesh has a central configuration to do all layouts via its decorators.xml besides you don’t have to create a definition for every page in your application (as in Tiles)
Patterns: Sitmesh is based on the wonderfully simple – Decorator Pattern. To apply a decorator to a page, you use a matching pattern definition in decorators.xml
Nesting decorators: Much like Tiles, you can always apply a decorator to a section of another decorator. You can even pass parameters to the Sub decorators just like you can in Tiles.
Flexibility: You can do just about anything you wanted! SiteMesh’s tag library consists of just 6 tags in total. SiteMesh is simple but still very flexible.
Fragments: Your decorators can be fully valid xhtml pages, or they can be small fragments that belong in a bigger page.
Tag Attributes: The writeEntireProperty attribute of the decorator:getProperty prevents you from having to do silly empty checks and conditional insertions of non-breaking spaces.
Separation from Content: You can finally keep your dynamic pages content-only! Use the decorators in combination with cascading style sheets to style your markup. Keep your content clean!
Atomic Pages: With Sitemesh, building atomic pages can be a breeze. When you have a page which has absolutely the content you want (let’s say, a results table). You can reuse this ‘atomic page’ in any other page you want in your webapp and even style it in different ways depending on where it’s included it. You don’t have to make them fragments and assume they’ll be properly wrapped with header, navigation, branding, footer, menu, by some other entity. Because Sitemesh rips out all the head and body tags you have ultimate control. Ultimately, this can help you reduce the total number of jsp files.
Less coupling: Using Tiles, you need to have your forwards go to a “tiles page”. Each individual page has to be associated with a layout, this is the biggest drawback! Every time you create a new JSP that you want to forward to, you have to create another tiles definition and associate it with a layout and forward to the Tile page (versus the JSP).
SiteMesh takes the approach that your page (JSP) doesn’t even know or care that it’s being decorated. Using SiteMesh, your pages don’t have to worry about a layout at all
URL Patterns, Custom Mapping: SiteMesh allows you to set up a URL pattern and the corresponding pages are decorated with the layout you choose. You can have decorators invoked based on many other ways other than a simple URL mapping by extending DecoratorMapper.
With Tiles, the whole concept of TilesRequestProcessor has never been easy to configure. For example, regarding your page chunking (headings etc) – you can already do this via the content blocks feature. Simply put content here into your page, and it will be available to your decorator as ‘page.x’. Also useful because without decoration browsers will ignore the tag, hence you can still preview your pages. You can use this technique for all sorts of things, for example you could use it to aggregate stylesheets as you talked about using … and then in your decorator display all of the stylesheets in your head tag – or something like that.
You can also define your own DecoratorMapper implementation which is basically a strategy that chooses which decorator to use for each request (it defaults to looking in a config file). This can be used to do more dynamic things such as different decorators based on locale, user, category, browser, whatever
The Cons:-
Inheritance: With Tiles, you can extend page definitions and override attributes. This feature seems to be completely lacking in SiteMesh. It would be nice to have something where you could specify the parent – for instance, to use the same content
Error page decoration: SiteMesh seems to be incapable of decorating error pages (i.e. 404) in Tomcat 5.0.x (even if I add ERROR to the filter-mapping). A workaround is to use wrap the error page with a
tag. This works, but if you specify elements in , they will end up in the body of page, rather than in the decorator’s header
Compile Errors: Compile errors can be difficult to debug specially when you nest decorators (sub decorators). Because you have to apply decorators from within error pages, you can end up w/ double branding, navigaiton, menus, etc.
Part of this content is inspired from other sources/blogs, I’m gonna keep this post ‘sticky’ and keep updating it as and when I come across interesting points.
![[Slashdot]](http://slashdot.org/favicon.ico)
![[Digg]](http://digg.com/favicon.ico)
![[Reddit]](http://reddit.com/favicon.ico)
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif)
![[Facebook]](http://www.facebook.com/favicon.ico)
![[Technorati]](http://technorati.com/favicon.ico)
![[Google]](http://www.google.com/favicon.ico)
![[StumbleUpon]](http://www.stumbleupon.com/favicon.ico)
3 Comments
Sounds interesting, can you post an example?
To decorate error-pages you have probably add a dispatcher attribute (for ERROR) to your filter-mapping. I guess your filter-mapping should look like this:
SiteMesh
*.jsp
REQUEST
ERROR
Damn. XML was stripped out.
Look this for an example:
http://www.jspinsider.com/showsource.jsp?resource=/WEB-INF/web.xml
Post a Comment