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
