java web app decorating/includes issues

Question

Background: we have a system that was written in an older CMS based on Java back during the 2002-2003 days. We want to keep moving forward with our new stuff, using tomcat, stripes, and sitemesh. We have navigation, layouts, "pods", js, css, etc, that we've taken out of the old CMS and into a few of our new apps so we have consistent look and feel.

We now need some sort of solution to get rid of all the code duplication going on. Our apps are running on the same VM at the moment, but that might change. We need a way for all of our tomcat instances to access some common elements (and those elements may/may not need to do some server side stuff).

The best we've come up with so far is making a fairly standard sitemesh decorator, that uses c:import to get what it needs, and plugs it right in. This solution has some network overhead which could bog it down and introduce a fail point. We've looked at <%@ include file="/something.jsp" %> as well but that seems to be only context relative. We could use c:import and point it at localhost, which seems to be the best solution so far.

Are there other templating/decorating frameworks out there (Tiles?) that could make this simpler? What are we missing?

Answer 1

I'm not quite sure what you're trying to do here. My interpretation is this: You have a number of resources that you want to reuse in a number of apps. You don't want to have these files duplicated in all apps, as it would make it hard to maintain consistency across the apps.

If this is your question, I would suggest that you keep your common resources in jar files. This gives you several advantages:

1. Your resources are local - no network overhead
2. You have control over updates to the resources.

An example of nr 2: You keep your common page layouts in page-layouts-1.x.jar. You keep on making minor releases of the page layouts that doesn't affect the apps using it - they are drop-in replacements. One day, you decide to redesign your apps completely and release page-layouts-2.0.jar. This require some rewrites to the apps using it. Now, if the apps bundles the page layouts, as opposed to keeping them in a shared class loader on the server, migrating to the 2.0 layout isn't an all or nothing affair. You can migrate one app at a time to use the 2.0 layout, while the others still use the 1.x layout.

We are doing this very successfully, using JSF and Facelets.

You might want to have a look at Weblets. I have no idea whether SiteMesh or Tiles got any direct support for serving up resources from the class path, but I assume you can tweak them to do this.

Hope it helps

Answer 2

We have used Sitemesh for years and I have mixed feelings about it.

I far prefer writing standard JSP tag files (.tag or .tagx) to use of applydecorator. I think the applydecorator tag effectively obsoleted with the advent of tag files, but too many Sitemesh users didn't notice.

Almost all of our Sitemesh usage was of this kind. We'd have a few common page templates, that our JSP pages would refer to explicitly as a layout. "Use the standard layout, here's the navigation menu and here's the body of the page." Tag files are an exact duplicate of this functionality, but they are standardized, supported by any J2EE web tool, and built-in to the container rather than another dependency.

For truly decorating a page, where the JSP page itself makes no reference at all to Sitemesh, I think it makes sense at a high-level, but I still don't like that the whole page is parsed again.

This second problem isn't Sitemesh's fault really; given the Servlet API it has to work with, I don't know what else it could do. But it does make me wonder if a DOM-based alternative to the stream-based Servlet API could be valuable. In other words, rather than having servlets write their output to a stream, what if they added nodes to a tree? This would enforce well-formed output, and make it cheaper to do structural transformations like Sitemesh does, or encode output to different formats like XHTML, HTML, or JSON on the fly.