A skin refers to a user interface's appearance; it gives a Web application a different look and feel. A skin changes the way the user interface appears when a user clicks a button, but does not change the UI's behavior. A change in the skin thus results in a change to an application's appearance, but to achieve that modification, your Web application must know how to use a skin.
Why should you skin a Web application in the first place? Well, there are several motives for using skins, but certainly they are not always a must. In a simple application, skinning it would be overkill, but in some situations, as described in the list below, you must deal with skins:
* When the skin is a system requirement: When the user can select his own skin or even create his own.
* When you want to give skin capabilities to an enterprise component framework: If you create different solutions for different clients, you could reuse all your components (taglibs), if your components have skinning capabilities, by just changing each client's skin.
* When a different skin is needed according to a business scenario: For example, in a marketplace or multi-banking application, different entities are working in the same system and you need to brand the application according to the user's corporate image.
Skinning a Web application is not an easy task. You can use Cascading Style Sheets and change an image's path, but you are limited to what you can do with CSS. If you have a component that looks completely different in each skin, that is, if the HTML differs in each skin, CSS won't help you. However, you could use CSS if simply changing styles solves your problem.
A good approach to creating a skin is to determine each piece of the user interface and generalize these pieces to apply an appearance to each one. For example, if, in Skin A, you have a frame component that is just a plain table and, in Skin B, a more complex table with headers, footers, images, and even sounds, different HTML (more
and tages) should be generated for each skin's frame. As an example, let's suppose that in Skin A, the HTML that must be generated to render a label is:
This is my Label
Now, in Skin B, this is how a label would be rendered:
As you can see, these two pieces of UI differ completely in each skin. They both have the same information (This is my Label), but are rendered with different HTML tags. This functionality couldn't be achieved with CSS alone. Perhaps using Extensible Stylesheet Language Transformations or XSL could be an option. Or you could use Xkins.
What is Xkins?
Xkins is a framework that manages skins for your Web application. In the early server-side Java days, you hard-coded HTML into a servlet. Then, JSP (JavaServer Pages) came along to allow you to put your HTML outside Java code. Nowadays, we have the same problem with taglibs that have HTML tags hard-coded in Java code. Using Xkins, you can place HTML outside your code with an additional and powerful feature: skins. For a detailed information about Xkins, visit Xkins's homepage.
Figure 1 illustrates Xkins's role in a Web application.
Figure 1. Xkins's role in a Web application
A Web application that uses Xkins and Struts through taglibs follows this request lifecycle:
* Struts initializes Xkins with the Xkins plug-in.
* Struts controller receives the HTTP request.
* Struts executes the process and forwards it to the JSP page view.
* The JSP page uses taglibs to render the page.
* The taglib uses Xkins through the Xkins facade: XkinProcessor.
* XkinProcessor gets the user's skin and the template that the taglib commands to render.
* XkinProcessor uses the TemplateProcessor associated with the template.
* The TemplateProcessor is the class responsible for rendering the UI piece that composes the skin. The TemplateProcessor could use Velocity, JBYTE (Java By Template Engine), Groovy, or other template engine to render the output.
* The TemplateProcessor uses the resources from the skin (elements and paths) and returns the result of the template processing to the taglib.
* The taglib renders the result of the template processing to the Web browser.
Xkins addresses skin management by following these basic concepts:
* Keep all HTML generation out of Java code: Taglibs usually generate HTML code. Changing this code requires changing the Java code and redeploying the application. Xkins allows you to externalize HTML generation by placing HTML in definition files (XML files). In addition, Xkins allows you to keep plain HTML formatting tags out of JSP pages to further externalize the application's look and feel.
* Define a skin structure: Templates, resources, and paths compose a skin. Resources can be either constants or elements like images and CSS files. Defining paths helps you organize your skin files. Defining templates helps you reuse the pieces of the UI throughout your application.
* Allow extensions to the Xkins framework: You can extend Xkins to use your own template language for rendering according to your needs. If you need, for example, image generation, you can implement a template processor that takes a template and generates an image. Xkins comes with template processors based on Velocity and JBYTE. If you prefer Groovy, for instance, you could create a Groovy template processor to render your UI pieces.
* Split UI in basic elements: In Xkins, you can strip all the UI's pieces and create templates with them. In this way, you can reuse these pieces and change anything you need to make a skin look different.
* Use inheritance to minimize skin maintenance: In Xkins, a skin can extend other skins and use all templates, paths, and resources that its parent has. Thus, you reduce template maintenance.
* Use composition to create skins: In addition to inheritance, Xkins also uses composition to minimize maintenance and promote reuse of your templates. With this feature, users can create their own personalized skins from your application by selecting different pieces of the UI from existing skins.
* Define a skin type: Using a skin type, you can assure that all skins loaded in an Xkins instance have at least the same templates as the type. A skin type is the skin of which all other skins must extend to be valid in an Xkins instance. By Xkins instance, I mean a group of skins loaded together for use by the Web application.
One important benefit Xkins offers is that all HTML is in one place, and, if you need to tune it, you just simply change the templates. For instance, if your pages are too big, detect where the excessive HTML generation is or decide what images could be stripped, and then change the templates to reduce page size. You could also have a lightweight skin for those users accessing your Web application with low-speed connections and a richer skin UI for broadband users.
