I'm suffering from option overload and need advice on how best to accomplish loading resources based on the User's current "skin." This would be something the user could set through an Action, and would be stored on the HttpSession.
I'd like to have one set of templates and page resources normally, but sometimes override them with files from an alternate location, IF a "skin" is in effect AND a replacement is available. A skin is simply a directory name, which contains a set of resources that should take precedence over the "normal" ones. Consider the following webapp layout: WEB-INF/decorators/default.ftl index.ftl css/default.css images/header.png WEB-INF/skins/NewSkin/decorators/default.ftl WEB-INF/skins/NewSkin/css/default.css WEB-INF/skins/NewSkin/images/header.png If "index.ftl" has a header logo thanks to the default SiteMesh decorator, but if the user indicates that they want to change their "skin" to "NewSkin" how best to "transparently" look for resources in an alternate location and fall-back to the default location if they don't exist? Currently, references to the header in the template look like: <img src="${base}/images/header.png" /> I'd like to avoid putting branches and skin logic in the templates themselves -- is there a lower layer, or a particular strategy that I should look into? I just don't know which of these avenues holds most promise: * A custom Struts2 theme * Wrapping every reference to any image in a "getFileLocation()" method call (perhaps from a BaseAction) that is itself aware of the current skin context * Using an OGNL expression in the FreeMarker result location parameter (good for templates, bad for things like images and css w/o more code in template) * Writing a servlet to serve up all .js, .css, and image files -- it would look for existence of the file in the skin, and if not found would fall-back and return the normal one * Somehow doing it at the SiteMesh layer -- perhaps a DecoratorMapper * Using my own JSP tag library within the FreeMarker templates to reference external resources Any guidance or ideas are appreciated! -rgm --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org