OpenSymphony has a nice little component called SiteMesh which allows you to use the decorator pattern to your web tier.

The content that you decorate doesn't need to know about the decorator which wraps it, and can in fact be any technology which produces HTML. SiteMesh was recently cleaned up as a 2.0 release, and some more work has just started.

Conclusion Excerpt

As we've seen, SiteMesh provides for a powerful, easy-to-use, non-intrusive mechanism for applying page templates. It's easy to envision a wide range of possible uses. For example, you might define a decorator that emits extra debugging information about the page, as determined by the browser (this is especially powerful when combined with a web browser that lets you set an arbitrary user-agent). You might define a decorator with a stripped-down XML output, allowing for easier automated testing. You can even use the decorator to grab content from other pages, for example, to simple portal-like capability.

Read Will Iverson's Introduction to SiteMesh

What I like about SiteMesh is that you can put it on top of anything else (jsp, struts, jsf, etc). However, I actually prefer the idea of outputting XML from my framework (jsf), and then using a transformation pipeline on the results (something like JSF -> XSLT (theme) -> XSLT (navigation, decorations) -> HTML), as this gives me more flexibility in the end, and I feel comfortable with XSLT. I believe this is now called Model 2X. Anyway, I'm currently investigating a "Model 2X" approach with JSF. Does anyone know of a Model 2X component that can rest on top of any other framework, like SiteMesh does?

XSLT has a certain attraction but it can be dog slow and eat up alot of memory. Are there any performance statistics for SiteMesh?

http://wiki.opensymphony.com/space/How+fast+is+Sitemesh%3F

My experience has been that SiteMesh is *really* fast. It's a little hard to pin down, as you're moving from one way of doing things to another. e.g. you'd want to compare adding a navbar with SiteMesh to adding a navbar in some other fashion.

Before SiteMesh, I had pages that used a lot of includes. They were a pain to maintain, very hard to update, etc. I investigated XSL[T], but it would have involved rewriting a LOT (although, I really did like the PDF generation in Cocoon).

When I switched to SiteMesh, I wound up going through and removing a lot of includes and other formatting from my subpages - way, way more than I would have ever guessed. Something very wonderful about deleting lots of unneeded code. :)

In any event, my testing was that my SiteMesh-based system was MUCH faster (not to mention easier to test and fewer lines of code) than what I was replacing.

Haven't looked back since...

Sitemesh is really, really fast.

We just had a round of optimisation a couple of months ago (for both memory and page parsing speed). I'd be surprised if anyone can find a faster hand-rolled html parser anywhere.

We've been using sitemesh for 8 months in a project now and I can't repeat often enough what a joy it is to remove jsp includes from serverpages and apply decorators instead.

Over the course of development we had an internal "quick and dirty" look and feel that we started with, and thanks to sitemesh it only took us 2 days to modify a few templates (and the css stylesheet) to change all that before the final release for the complete webapp. Now that is what I call productivity increase!

On the performance side - we didn't really test it, but have nothing negative to report either.

Well curiousity got the better of me so I downloaded SiteMesh and performed a few tests with WebLogic 8.1. The baseline JSP had an average response time of 20 milliseconds while the "decorated" version had a 70 millisecond average (both produced identical HTML and had a counter).

We are using a simple filter that allows post-processing right in JSP:
http://www.servletsuite.com/servlets/generic1flt.htm

So our decorator here is an ordinary JSP page with JSTL, Jakarta taglib etc. whatever you need

Glancing over the docs, it seems like there are nice features, but what is the advantage of SiteMesh in a JSP environment? Using JSTL and JSP imports don't really offend me personally. I get centralized templates and page-level conditionals pretty easily then. Why would I want to use sitemesh in place of that?

I can see with the filters that would be a nice advantage for being able to apply decorators to static content.. but what about in a pure JSP/dynamic environment?

Glancing over the docs, it seems like there are nice features, but what is the advantage of SiteMesh in a JSP environment? Using JSTL and JSP imports don't really offend me personally. I get centralized templates and page-level conditionals pretty easily then. Why would I want to use sitemesh in place of that?
I can see with the filters that would be a nice advantage for being able to apply decorators to static content.. but what about in a pure JSP/dynamic environment?

Because your pages don't have to know they're being decorated. You don't have to put includes in your pages, the filter will just wrap them in your decorators and they'll come out looking like the rest of your site, with the header, navbar, footer, or whatever you've defined there.

Probably nobody following this thread anymore but....

Going back to Paul's question, what advantages does SiteMesh give over building from scratch using JSP and someting like JSP Templates (http://java.sun.com/developer/technicalArticles/javaserverpages/jsp_templates/) or Struts Tiles.

Not being critical - SiteMesh seems like a great idea and I can definitely see huge benefit re static content or in a "rebranding" type scenario where you've no control over generation etc but if there are additional benefits over Tiles or JSP Templates approach (building from scratch with JSP) I'd be interested in hearing.

Because you don't have to mix your template in with the rest of your application. For example, in the jsp templates example, you're putting information in the JSP page about things like where the nav bar should appear, including the header and footer manually, etc.

With SiteMesh, you don't have to worry about any of that. The example for the JSP page uses fragments of HTML included in a lump. With SiteMesh, you build extremely thin but valid [X]HTML pages, and then the SiteMesh decorators are used at runtime to configure things like which stylesheet to use, etc.

I regularly use SiteMesh w/new projects - it's very easy to convert existing projects over, but obviously for new projects it's even easier.

Thanks Will.


Because you don't have to mix your template in with the rest of your application. For example, in the jsp templates example, you're putting information in the JSP page about things like where the nav bar should appear, including the header and footer manually, etc.


Good point - SiteMesh is definitely less intrusive and probably supports more finegrained decoration but I think the point about "putting information in the JSP page" probably sounds worse than it really is. I think this because the only pages you are putting information into (i.e. JSP Template tags) is the template page and the page "under the URL" and these are simply responsible for content aggregation (i.e. not "real content") - you probably won't have to many templates. The "real content" (the page components/portlets) don't/shouldn't have any template tags in there at all.

I think one of the really nice things about SiteMesh (from what I can see - really need to try it when I get a chance), and this just reiterates the point you made, is how it allows you to do things like the selection of the layout/template based on the useragent in a manner which is decoupled from content and it's creation - this type of thing is impossible with something like JSP Templates (impossible to do cleanly).

Sounds like I'm contradicting myself. Basic point I'm making is that maybe there is a case sometimes for something like JSP Templates - simple tag based approach with no config files, not interested in different useragents etc, and possibly (??) a bit more performant (because there's no parsing other than during compilation). While at the same time recognising that SiteMesh would appear to be a far nicer solution.

SiteMesh is simply cool!

buffalo search engine optimization

havent tried Sitemesh yet

stork club new york