Understanding Skins
An Content Delivery skin contains all of the resources that make up a user interface and some files which drive application behavior. Everything in the appearance, layout, and style of Content Delivery user interfaces are defined within a skin.
In order to facilitate easy customization, skins are organized into hierarchies using parent-child relationships. The root of every hierarchy is the base skin, which contains all of the default UI elements required to run the application.
Whenever a resource is requested, the application locates it and loads it from within a skin. If the requested resource does not exist in the current skin, its parent is checked for the resource. If at any time the resource is found, it is returned. If it is not found in a skin, the application checks the skin's parent. This continues up the hierarchy until the base is reached, at which point a 404 error or HTML page will be returned if the resource is still not found.
This allows you to only add resources to your skin that are new or that you are changing. If there is an image, JavaScript or XSL file in the base skin that you do not intend to change for your customization, you can allow it to be loaded from the base skin.
The skin hierarchy is established by a simple "dot" notation. For example, you could create the following skins: galaxy, galaxy.system, galaxy.system.neptune, and forensics. You then select the skin in Global Config as galaxy.system.neptune. If a style format is not found in galaxy.system.neptune, Content Delivery looks for it in galaxy.system. If not found there, it looks in galaxy. If not found there, it looks in base. If still not found, an error occurs.
The galaxy skins do not inherit from forensics. Similarly, forensics does not inherit any styles from galaxy. Additionally, the galaxy.system skin does not inherit from the galaxy.system.neptune skin.
Within each skin, the types of UI elements that you can add or modify are listed in the table below. By placing modified versions of these resources into your own skins, you can customize the appearance and behavior of the Content Delivery application.
| Resource | Description |
|---|---|
| CSS | Defines classes and appearance of HTML elements (typography, colors, and so on). |
| HTML | HTML templates that define the basic structure and loading of a page, or HTML components (such as the header bar) which are loaded into a page on-demand. |
| JavaScript | Scripting that drives interactivity and application functionality (content loading, field-level validation, and so on). |
| Images | Graphics files (icons, logos, and so on). |
| XForms | Defines the layout and allowable content for the user-generated content available in the application. For example, issue reports and comments. XForms are rendered and presented in modal dialogs, allowing the user to create the form content. Relies on the W3C XForm XML standard. |
| XML Configuration files | Define the layout of the different interfaces and which JavaScript components to load. Includes setting up your components and panels (sub-windows) and language files for all the textual content on your pages, error messages and localized strings to use within the UI based on the selected language. |
| XQuery | Special snippets of XQuery used to drive periodically scheduled jobs or other custom application functionality. An example would be to provide an additional sorting routine for search results. |
| XSL Stylesheets | Filters and renders dynamic content and XML documents into HTML or PDF. These stylesheets also take part in rendering large parts of the user interface, and assist in preparing XML content. The XSL stylesheets are organized into sub-folders. The ui sub-folder contains all the XSL used to build the user interface, while common contains XSLs used by multiple XML standards. There are also sub-folders for each individual XML standard, such as DITA. |