Why Skinning?
CSS is the tool for webdevelopers (or more likely designers) to customize sites without having to alter code. This allows for visual variability without the need to compile/test/deploy/… things. It also allows user-specific theming where the user can decide which theme looks best.
However there is one thing notably lacking in css: variables. They may be introduced in CSS3 but it will be a ways before they are actually picked up by all major browsers. Until then we can look at other frameworks to see how they achieve skinning in JSF, most notably Richfaces. This document is written using richfaces as a guideline but does not actually require any richfaces components to be present so it can be used with any JSF framework.
Richfaces skinning
Richfaces supports skinning by using a simple properties file to represent the variables. The properties file must:
- be located in META-INF/skins
- have the extension “skin.properties”
For example you might create a skin “META-INF/skins/test.skin.properties”. To tell richfaces to use this skin, you have to configure a context parameter in the web.xml file:
<context-param>
<param-name>org.richfaces.skin</param-name>
<param-value>test</param-value>
</context-param>
You can take an existing skin file to see which variables exist or you can browse the component pages to see which variables they reference. Additionally richfaces will by default (you can turn this off) style regular jsf components as well in order to create a single theme for the entire application.
Using the variables yourself
Of course you don’t only want to skin existing richfaces components, you may want to use the variables in the css of your own components/pages. In order to do this, you need to create a file with an extension “.ecss” instead of “.css”. This will be automatically picked up by richfaces and the variables inside it will be replaced with the properties available in the skin file. Each variable must be written like this:
‘#{richSkin.myParam}’
The quotes are mandatory. There are however a number of caveats.
Library lookups are wonkyRichfaces will translate your ecss outputStylesheet to something like this:
<link type = “text/css” rel = “stylesheet”
href = “/app/rfRes/myStyleSheet.ecss.xhtml?db=eAHb-CCOEQAGJQHx” />
Which is fine unless you add the style sheet to a library, then it will generate this (note the escaped ampersand):
<link type = “text/css” rel = “stylesheet”
href = “/app/rfRes/myStyleSheet.ecss.xhtml?db=eAHb-CCOEQAGJQHx&ln=style” />
I’m not entirely sure if the problem lies with richfaces (I don’t really see an obvious bug in the code with regards to URI encoding) or with jsf in general but either way it is a bit off. This may work depending on the browser, not sure how well supported this is though. Anyway, you can easily sidestep this by not putting it in a resource library and simply adding stuff on the root.
Eclipse does not like ecss files
Eclipse does not always like the variable format ecss uses. Depending on your level of bad luck you either get badly highlighted css or continuous parsing errors resulting in error popups.
Custom css properties are dropped
It is a long standing tradition to introduce new css features in browsers with a prefix for said browsers. For example take this bit of css which includes a chrome/firefox gradient and a firefox/general box-sizing declaration:
.menu .main a {
background: -webkit-gradient(linear, left top, left bottom, from(‘#{richSkin.menuGradientLight}’), to(‘#{richSkin.menuGradientDark}’));
background: -moz-linear-gradient(top, ‘#{richSkin.menuGradientLight}’, ‘#{richSkin.menuGradientDark}’);
padding: 0px 10px;
padding-top: 8px;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
When I browsed the resulting compiled ecss, I got this:
*.menu *.main a {
background: webkit-gradient(linear,lefttop,leftbottom,from(rgb(64,64,64)),to(rgb(43,43,43)));
background: webkit-gradient(linear,lefttop,leftbottom,from(rgb(64,64,64)),to(rgb(43,43,43)));
padding: 0px 10px;
padding-top: 8px;
}
As you can see, it dropped the mozilla gradient and both the mozilla and default box-sizing properties. This is likely because richfaces actually interprets the css instead of merely replacing the variables. The colors were also defined as hexadecimal and converted to their rgb equivalent. Apart from validation, I’m not entirely sure why richfaces bothers parsing the css.
Custom variable styling
To work around the issues mentioned above, I wrote my own stylesheet compiler. It requires a few things to function:
- stylesheets must use the extension “.compiled.css” instead of “.css”, so for example “mystyle.compiled.css” will be picked up by the stylesheet compiler
- it currently uses the richfaces web.xml property mentioned above to determine which skin file you want and also scans for the “META-INF/skins/<name>.skin.properties” file, in that respect it is compatible with richfaces
The variable format is slightly more lightweight, it uses “$”, the css fragment in the above would become:
.menu .main a {
background: -webkit-gradient(linear, left top, left bottom, from($menuGradientLight), to($menuGradientDark));
background: -moz-linear-gradient(top, $menuGradientLight, $menuGradientDark);
padding: 0px 10px;
padding-top: 8px;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
Bits and pieces
The stylesheet compiler is a standalone jar file which can be plugged into any war file. It contains the following things.
CSSResourceHandler.java
First off you need to provide a custom implementation of the jsf resource handler. Based on this tutorial and the richfaces implementation it looks like this:
public class CSSResourceHandler extends javax.faces.application.ResourceHandlerWrapper {
private Logger logger = LoggerFactory.getLogger(getClass());
private Properties skinProperties;
private ResourceHandler wrapped;
public CSSResourceHandler(ResourceHandler wrapped) {
logger.debug(“Creating custom resource handler with parent {}”, wrapped);
this.wrapped = wrapped;
}
@Override
public ResourceHandler getWrapped() {
return wrapped;
}
@Override
public Resource createResource(String resourceName, String library, String contentType) {
logger.trace(“createResource(“ + resourceName + “, “ + library + “, “ + contentType + “)”);
// get the resource in the conventional way
Resource resource = super.createResource(resourceName, library, contentType);
// if the resource is a “.compiled.css” file, compile it
if (resourceName.endsWith(“.compiled.css”))
return new CompiledCSS(resource, getSkinProperties());
else
return resource;
}
@Override
public Resource createResource(String resourceName, String library) {
return createResource(resourceName, library, null);
}
@Override
public Resource createResource(String resourceName) {
return createResource(resourceName, null, null);
}
@Override
public String getRendererTypeForResourceName(String resourceName) {
if (resourceName.endsWith(“.compiled.css”))
return “javax.faces.resource.Stylesheet”;
else
return super.getRendererTypeForResourceName(resourceName);
}
private Properties getSkinProperties() {
if (skinProperties == null) {
// we need to figure out which skin is configured
FacesContext context = FacesContext.getCurrentInstance();
// get the richfaces skin parameter
String skin = context.getExternalContext().getInitParameter(“org.richfaces.skin”);
// the default skin
if (skin == null)
skin = “DEFAULT”;
// in richfaces, the context class loader is used, not the faces context method of resource discovery
// note that the path must follow the below convention as per richfaces documentation & implementation
InputStream input = Thread.currentThread().getContextClassLoader().getResourceAsStream(“META-INF/skins/” + skin + “.skin.properties”);
if (input != null) {
logger.debug(“Loading skin “ + skin);
skinProperties = new Properties();
try {
try {
skinProperties.load(input);
}
finally {
input.close();
}
}
catch (IOException e) {
throw new RuntimeException(e);
}
}
else
logger.error(“Could not find skin “ + skin);
}
return skinProperties;
}
}
As you can see, it simply delegates most resource calls to the wrapper that it was initiated with. Only when the extension “.compiled.css” is found does it kick in. If the web.xml context parameter is not set, it will fall back to the richfaces default.
CompiledCSS.java
The compiled css class extends resource and much like the handler, delegates nearly all calls. It intercepts the request for content though and performs a replace on the original content before sending it back:
public class CompiledCSS extends Resource {
private Resource original;
private String cached;
private Properties skinProperties;
public CompiledCSS(Resource original, Properties skinProperties) {
this.original = original;
this.skinProperties = skinProperties;
}
/**
* This is where we actually convert the css
*/
@Override
public InputStream getInputStream() throws IOException {
if (cached == null) {
// copy to string
ByteArrayOutputStream output = new ByteArrayOutputStream();
byte [] buffer = new byte[102400];
int read;
InputStream source = original.getInputStream();
try {
while ((read = source.read(buffer)) != -1)
output.write(buffer, 0, read);
}
finally {
source.close();
}
cached = new String(output.toByteArray());
for (Object key : skinProperties.keySet())
cached = cached.replaceAll(“\$” + key.toString(), skinProperties.get(key).toString());
}
return new ByteArrayInputStream(cached.getBytes());
}
@Override
public String getRequestPath() {
return original.getRequestPath();
}
@Override
public Map<String, String> getResponseHeaders() {
return original.getResponseHeaders();
}
@Override
public URL getURL() {
return original.getURL();
}
@Override
public boolean userAgentNeedsUpdate(FacesContext context) {
return original.userAgentNeedsUpdate(context);
}
@Override
public String getContentType() {
return “text/css”;
}
}
META-INF/faces-config.xml
You need to tell JSF to use your custom resource handler, you can do this in the faces-config file:
<faces-config
xmlns = “http://java.sun.com/xml/ns/javaee”
xmlns:xsi = “http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation = “http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd”
version = “2.0”>
<application>
<resource-handler>com.example.web.common.CSSResourceHandler</resource-handler>
</application>
</faces-config>
At this point I’m not entirely sure how this works. Apart from the mandatory faces-config.xml file in your main war, you can apparantly have faces-config.xml files in your libraries as well. Richfaces registers its own resource handler and since both frameworks still work, JSF must register both instead of having a “the last setting wins” policy. How this plays out at runtime (are all the handlers stacked in order of appearance? Is it a flat list of handlers that is looped through?…) is unclear at this point.
Putting it together
Suppose you have a separate jar which defines some templates/components and most notably: some styling. The jar layout is as follows:
- META-INF: everything must be in meta-inf for jsf to pick it up
- resources: all jsf-related resources including templates must be available in the resources folder
- style: the library “style”
- default.compiled.css
- templates
- layout.xhtml
- style: the library “style”
- skins
- custom.skin.properties
- resources: all jsf-related resources including templates must be available in the resources folder
Suppose we define a very simple layout.xhtml:
<html xmlns = “http://www.w3.org/1999/xhtml”
xmlns:h = “http://java.sun.com/jsf/html”
xmlns:f = “http://java.sun.com/jsf/core”
xmlns:rich = “http://richfaces.org/rich”
xmlns:a4j = “http://richfaces.org/a4j”
xmlns:ui = “http://java.sun.com/jsf/facelets”>
<h:head>
<title>
<ui:insert name = “title”/>
</title>
<h:outputStylesheet name = “default.compiled.css” library = “style”/>
</h:head>
<h:body><ui:insert name = “main”/></h:body>
</html>
As you can see, we can reference the compiled stylesheet as we would a normal stylesheet. Now suppose we have this bit in the stylesheet:
.menu .main a {
background: -webkit-gradient(linear, left top, left bottom, from($menuGradientLight), to($menuGradientDark));
background: -moz-linear-gradient(top, $menuGradientLight, $menuGradientDark);
padding: 0px 10px;
padding-top: 8px;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
Then we need to add the properties to the custom.skin.properties file:
menuBorderColor=#666666
menuGradientLight=#404040
menuGradientDark=#2b2b2b
When you open the css as it is retrieved by the browser, you will see:
.menu .main a {
background: -webkit-gradient(linear, left top, left bottom, from(#404040), to(#2b2b2b));
background: -moz-linear-gradient(top, #404040, #2b2b2b);
padding: 0px 10px;
padding-top: 8px;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
If you package this as a “theme” library for your jsf applications, you can create an index.xhtml in your main war file that contains:
<ui:composition xmlns = “http://www.w3.org/1999/xhtml”
xmlns:h = “http://java.sun.com/jsf/html”
xmlns:f = “http://java.sun.com/jsf/core”
xmlns:rich = “http://richfaces.org/rich”
xmlns:a4j = “http://richfaces.org/a4j”
xmlns:ui = “http://java.sun.com/jsf/facelets”
template = “templates/layout.xhtml”>
<ui:define name = “main”>
<p>the main content comes here!</p>
</ui:define>
</ui:composition>
Author: Alexander Verbruggen