Java web app beautifies / includes issues
Background: we have a system that was written in an older Java-based CMS during the 2002-2003 days. We want to keep moving forward with our new stuff using tomcat, stripes and sitemesh. We have navs, layouts, "pods", js, css, etc. that we have pulled from the old CMS and into some of our new applications so that we have a consistent look and feel.
Now we need some kind of solution to get rid of all the code duplication. At the moment, our applications are running in the same virtual machine, but this may change. We need a way for all tomcat instances to access some common elements (and those elements may / may not need to do some server-side stuff).
The best thing we've come up with so far is to make a pretty standard sitemesh decorator that uses c: import to get what it needs and hooks it up directly. This solution has some network overhead that can crash and introduce a point of failure. We've also looked at <% @include file = "/something.jsp"%>, but this seems to be context-specific only. We could use c: import and point it to localhost, which seems like a better solution.
Are there other templates / decorating frames (Tiles?) Out there that could make this easier? What are we missing?
source to share
I'm not really sure what you are trying to do here. My interpretation is that you have multiple resources that you want to reuse across a number of applications. You do not want these files to be duplicated across all applications, as it would be difficult to maintain consistency across applications.
If this is your question, I suggest that you save your shares in jar files. This gives you several benefits:
- Your resources are local - no network overhead
- You have control over resource updates.
Example nr 2: You save your general page layouts in page-layouts-1.x.jar. You keep making small releases of page layouts that don't affect the apps that use it - they replace the replacement. One day you decide to completely redesign your applications and release page-layouts-2.0.jar. This requires some rewriting applications to use it. Now, if applications bind page layouts as opposed to storing them in a shared classloader on the server, moving to layout 2.0 is not all or nothing. You can migrate one app at a time to use the 2.0 layout, while the others still use the 1.x layout.
We do this very successfully using JSF and Facelets.
You might want to take a look at Weblets . I don't know if SiteMesh or Tiles got direct support for serving resources from the classpath, but I assume you can configure them to do so.
Hope it helps
We've been using Sitemesh for years and I have mixed feelings about this.
I prefer to write standard JSP tag files (.tag or .tagx) to use applydecorator. I think the applydecorator tag is effectively deprecated with the advent of tag files, but too many Sitemesh users haven't noticed.
Almost all of our uses of Sitemesh have been of this kind. We will have some generic page templates that our JSP pages will refer explicitly to the layout. "Use the standard layout, here the navigation menu and the body of the page here." Tag files are an exact duplicate of this feature, but they are standardized, supported by any J2EE web tool, and are built into the container, not with another dependency.
To really beautify a page where the JSP page itself does not link to Sitemesh at all, I think it makes sense at a high level, but I still don't like the whole page being parsed again.
This second problem is not a Sitemesh bug; given the servlet API it needs to work with, I don't know what else it could have done. But I'm wondering if there might be a useful DOM-based alternative for the Stream-based Servlet API. In other words, instead of having servlets write their output to a stream, what if they added nodes to the tree? This would provide correct output and make it cheaper to perform structural transformations such as Sitemesh, or encode the output into different formats such as XHTML, HTML, or JSON on the fly.
source to share