Contents
Previous
Next
| UIX Developer's Guide |
Contents |
Previous |
Next |
This chapter discusses the UIX customization technologies provided by facets and UIX Styles.
UIConstants.FACET_PRINTABLE: Eliminates all chrome in page layouts, deactivates all links, and makes all form elements read-only.
UIConstants.FACET_PORTLET: Optimizes the imports of CSS stylesheets and (where possible) Javascript libraries to improve performance when multiple portlets each try to load the same stylesheets and libraries in a single page.
ServletRenderingContext (or RootRenderingContext) with the setFacet() method. A facet must be set before the RenderingContext is used to render any content.
There is also a <showFacet> event handler that lets you declaratively show a facet. This is especially useful for showing printable pages. An example follows:
<ctrl:page xmlns="http://xmlns.oracle.com/uix/ui"
xmlns:ctrl="http://xmlns.oracle.com/uix/controller">
<ctrl:content xmlns:ui="http://xmlns.oracle.com/uix/ui">
<body>
<contents>
<form name="theForm">
<contents>
<pageLayout>
<start>
<sideBar>
<contents>
<link text="test"/>
</contents>
</sideBar>
</start>
<pageButtons>
<button ctrl:event="printMe" text="Printable Version"/>
</pageButtons>
<contents>
<messageTextInput prompt="Database" text="Oracle"/>
</contents>
</pageLayout>
</contents>
</form>
</contents>
</body>
</ctrl:content>
<ctrl:handlers>
<ctrl:event name="printMe">
<ctrl:showFacet name="printable"/>
</ctrl:event>
</ctrl:handlers>
</ctrl:page>
UIX's rendering technologies use Cascading Style Sheet (CSS) styles to control the visual appearance of the Browser Look And Feel, Oracle's corporate look and feel for HTML applications. One of the goals of Cascading Style Sheets is to allow presentation styles, such as fonts and colors, to be separated from the HTML content to which the styles are applied. This allows these styles to be customized without modifications to the HTML content, or in the case of UIX applications, without modifications to the code which generates the HTML content.
Defining CSS styles is very simple. Each style definition consists of a "selector", which associates the style with a particular element or sets of elements in an HTML document, and a "declaration" of the properties defined by the style. The following sample shows a CSS style which uses a class-based selector:
.OraFieldText {font-family:Arial; font-size:10pt; color:#000000}
In this example, the selector ".OraFieldText" indicates that the properties
defined by this style should be applied to any HTML element with a class
attribute value of "OraFieldText". So, the
.OraFieldText style should be applied to the
following text, which should be rendered by the browser in black with a 10
point Arial font:
<span class="OraFieldText">Some stylized text</span>
Although CSS makes it easy to define and customize presentation styles,
managing CSS styles can become a complex task. It is often the case that
one set of CSS styles is not sufficient for all target environments. That is,
style definitions may need to be modified to better support a specific end user
environment. The definition for a particular style may vary based on the end
user's locale, browser, platform, or some other environment-specific
property. For example, the
.OraFieldText style might require
a different font family (for example, "MS Mincho" instead of Arial) and
font size (12 point instead of 10 point) when displaying
Japanese content.
One solution to this problem is to place environment-specific style definitions in environment specific style sheets. For example, generic style definitions can be placed in a style sheet file named "styles.css". Japanese style definitions can be placed in "styles-ja.css", browser-specific style sheets can be placed in "styles-netscape.css" and "styles-ie.css". However, this solution quickly becomes difficult to manage. The number of possible style sheets required to satisfy all users in all environments grows very fast. For example, in addition to "styles-ja.css" and "styles-netscape.css", it may be necessary to define "styles-ja-netscape.css", "styles-ja-ie.css", as well as "styles-ja-ie-windows.css", "styles-ja-ie-macintosh.css", "styles-ja-netscape-windows.css", "styles-ja-netscape-macintosh.css", "styles-zh_TW-ie-4-windows.css", etc...
Maintaining such a set of environment-specific style sheets can be error prone. In particular, it is very easy for the code which selects the style sheet to use to get out of sync as new style sheets are added. Also, this solution requires a large amount of style definition duplication. This means that if a style definition needs to be changed, it is quite likely that the change may need to be propagated to every style sheet.
UIX's style management framework, UIX Styles, attempts to avoid this complexity by consolidating style definitions for all end user environments into a single XML style sheet document.
UIX Styles's XML Style Sheet Language (XSS) is an XML language for describing
presentation styles. The XSS language is based on CSS. As
with CSS, XSS defines styles using a selector and a set of properties.
The main difference between XSS and CSS is that XSS is XML-based. For
example, the CSS .OraFieldText style defined
above is defined in XSS with the following XML elements:
<style selector=".OraFieldText">
<property name="font-family">Arial</property>
<property name="font-size">10pt</property>
<property name="color">#000000</property>
</style>
XSS does not place any restrictions on the selectors, property names, or property values. Any valid CSS selector, property name or property value can be specified in an XSS document.
Another important difference between XSS and CSS is that XSS allows
styles to be defined for specific end user environments. This is done
by placing the environment-specific styles within a
<styleSheet>
element. The <styleSheet>
element specifies attributes which indicate
the locales, browsers and platforms to which the styles should be applied.
The following XSS document defines three sets of styles. The
first <styleSheet>
defines styles which are applied to all environments.
The second <styleSheet> defines styles
which are specific to
Japanese. The third <styleSheet>
defines styles which are specific
to the Microsoft Windows platform.
<?xml version="1.0"?>
<styleSheetDocument xmlns="http://xmlns.oracle.com/uix/style">
<!-- The base style sheet. The styles defined in this style sheet
apply to all environments -->
<styleSheet>
<style selector=".OraFieldText">
<property name="font-family">Arial</property>
<property name="font-size">10pt</property>
<property name="color">#000000</property>
</style>
</styleSheet>
<!-- A style sheet for Japanese-specific styles -->
<styleSheet locales="ja">
<!-- Use a larger font size for Japanese text -->
<style selector=".OraFieldText">
<property name="font-size">12pt</property>
</style>
</styleSheet>
<!-- A style sheet for MS Windows platforms -->
<styleSheet platforms="windows">
<!-- Use a Windows-specific Japanese font family -->
<style selector=".OraFieldText">
<property name="font-family">MS Mincho</property>
</style>
</styleSheet>
</styleSheetDocument>
At runtime, UIX Styles determines which styles should be applied based on
information provided with the HTTP request, such as the end user's
agent, platform and locale. If a single style is defined in multiple
<styleSheet> elements, property
values defined in more specific style sheets take precedence.
For example, a property for a style defined in the
<styleSheet locales="ja"> element takes
precedence over the same property in the same style in the
base <styleSheet> element. If the
same style is defined in multiple style sheets which are all applicable
to the current end user environment, a set of specificity rules is applied
to determine which style definition should take precedence.
Once UIX Styles has determined which styles
should be applied to a particular request, UIX Styles generates a CSS style
sheet containing the environment-specific CSS style definitions.
The generated
environment-specific CSS style sheet can then be referenced from the HTML
document via a <link> element in the
document's <head> section. (Note: UIX Controller
automatically generates the correct style sheet link for UIX-based
applications.)
Using the sample XSS document defined above, a CSS style
sheet for Japanese users on the Windows platform would be generated by
UIX Styles by combining the styles from all three
<styleSheet> elements. However, for
English users on the Windows platform, only styles from the base style
sheet (that is, the <styleSheet> element
with no attributes) and the Windows-specific
<styleSheet> would be applied.
Similarly, for English users on some non-Windows platform, such as
Macintosh or Linux, only styles from the base style sheet are applied.
UIX Styles and the XML Style Sheet Language makes it easy to define
and manage environment-specific style customizations. All such
customizations can be specified incrementally within a single document.
Different types of customizations (for example, browser-specific,
platform-specific, locale-specific customizations) are automatically
combined by UIX Styles as needed based on the target end user environment.
Since styles from all applicable
<styleSheet> elements are merged by UIX Styles,
there is no unnecessary style definition duplication.
The XML Style Sheet Language provides another feature which reduces the amount of work necessary to define and maintain environment-specific styles: style includes. Often, a large number of style definitions may share common properties, such as a base font size or a standard background color. XSS allows such common properties to be defined in a "named style", which can be referenced by any other style in the XSS document. The following sample XSS document shows a named style which defines common font properties shared by other styles:
<?xml version="1.0"?>
<styleSheetDocument xmlns="http://xmlns.oracle.com/uix/style">
<!-- The base style sheet. The styles defined in this style sheet
apply to all environments -->
<styleSheet>
<style name="DefaultFont">
<property name="font-family">Arial</property>
<property name="font-size">10pt</property>
</style>
<style selector=".OraFieldText">
<includeStyle name="DefaultFont">
<property name="color">#000000</property>
</style>
<style selector=".OraLinkText">
<includeStyle name="DefaultFont">
<property name="color">#663300</property>
</style>
<style selector=".OraTipText">
<includeStyle name="DefaultFont">
<property name="color">#336699</property>
</style>
</styleSheet>
<!-- A style sheet for Japanese Windows-specific styles -->
<styleSheet locales="ja" platforms="windows">
<style name="DefaultFont">
<property name="font-size">12pt</property>
</style>
</styleSheet>
</styleSheetDocument>
In the above example, the "DefaultFont" named style is used to
define font-related properties for the three other styles, each of which
references the "DefaultFont" using the
<includeStyle> element.
The default font properties are overridden for Japanese Windows users
via a single style definition, rather than by overriding each style definition
individually. UIX Styles's style inclusion functionality allows for
very concise style customizations, with a minimal amount of duplication.
UIX's implementation of the Browser Look And Feel takes advantage of UIX Styles's ability to define end user environment-specific styles. Style definitions for the Browser Look And Feel are defined by the blaf.xss style sheet document, which is distributed with UIX. UIX clients may find that it is necessary to modify the default styles defined by blaf.xss in order to address the style requirements for particular customers. Since blaf.xss defines the default styles used by UIX, blaf.xss should never be modified directly. Instead, customer-specific style definitions should be placed in a customer-specific XSS document. That way, customers can upgrade to new versions of blaf.xss as they become available, without requiring customer-specific styles to be repeatedly merged into new versions of blaf.xss.
When defining customizations to the Browser Look And Feel styles, the
XML Style Sheet Language <import>
element should be used to include the styles defined by blaf.xss within
the custom style sheet. The following sample shows a custom style sheet
which imports blaf.xss and then modifies the default font size:
<?xml version="1.0"?>
<styleSheetDocument xmlns="http://xmlns.oracle.com/uix/style">
<!-- Import blaf.xss, so that our style sheet includes all styles
defined by blaf.xss -->
<import href="blaf.xss"/>
<!-- A custom style sheet which overrides DefaultFont -->
<styleSheet>
<style name="DefaultFont">
<property name="font-family">Courier</property>
<property name="font-size">14pt</property>
</style>
</styleSheet>
</styleSheetDocument>
When this custom XSS document is used, any styles in blaf.xss which reference the "DefaultFont" named style will honor the new customized style definition (14pt, Courier).
The name of the style sheet
document to use when rendering with UIX can be specified via the
Configuration.STYLE_SHEET_NAME property.
The location of the style sheet document, along with the cache of
generated CSS files can be modified via the
Configuration.STYLES_DIRECTORY and
Configuration.STYLES_CACHE_DIRECTORY
paths.
Perhaps one of the most common customizations that customers may want to make to the Browser Look And Feel is to modify the default font. Due to the widespread use of style includes in blaf.xss, making this change is very simple. Although blaf.xss defines roughly one hundred different styles which specify font properties, all of these styles refer to a single named style which defines the default font family value:
<!-- The default font family -->
<style name="DefaultFontFamily">
<property name="font-family">Arial, Helvetica, Geneva, sans-serif</property>
</style>
So, changing the font family property for all styles defined by blaf.xss requires a single style override. The following custom style sheet changes the default font family to the CSS "serif" font family:
<?xml version="1.0"?>
<styleSheetDocument xmlns="http://xmlns.oracle.com/uix/style">
<!-- The blaf.xss import -->
<import href="blaf.xss"/>
<!-- A custom style sheet which overrides DefaultFontFamily -->
<styleSheet>
<style name="DefaultFontFamily">
<property name="font-family">serif</property>
</style>
</styleSheet>
</styleSheetDocument>When this custom style sheet is used, the Browser Look And Feel adopts the "serif" font family across all components.
Of course, it is also possible to override the font family (or any other
style properties) for specific styles. For example, the following
custom style sheet changes the default font to "serif", while specifying
that the "Arial" font family should be used for the
.OraFieldText style:
<?xml version="1.0"?>
<styleSheetDocument xmlns="http://xmlns.oracle.com/uix/style">
<!-- The blaf.xss import -->
<import href="blaf.xss"/>
<!-- A custom style sheet which overrides DefaultFontFamily -->
<styleSheet>
<style name="DefaultFontFamily">
<property name="font-family">serif</property>
</style>
</styleSheet>
<!-- Let's keep using Arial for .OraFieldText -->
<styleSheet>
<style selector=".OraFieldText">
<property name="font-family">Arial</property>
</style>
</styleSheet>
</styleSheetDocument>Another common customization to the Browser Look And Feel is to change the default font size. Almost all of the styles defined in blaf.xss reference a common named style which defines the default font size:
<!-- The default font -->
<style name="DefaultFont">
<includeStyle name="DefaultFontFamily"/>
<property name="font-size">10pt</property>
</style>
So, changing the default font size requires a single style override, as shown in the following custom style sheet document:
<?xml version="1.0"?>
<styleSheetDocument xmlns="http://xmlns.oracle.com/uix/style">
<import href="blaf.xss"/>
<styleSheet>
<!-- Change the default font to be 12 point -->
<style name="DefaultFont">
<property name="font-size">12pt</property>
</style>
</styleSheet>
</styleSheetDocument>The Browser Look And Feel does make use of several other font sizes. For example, smaller font sizes are used for inline messages; larger font sizes are used for headers. blaf.xss defines named styles for each font size used by the Browser Look And Feel:
<!-- A very small font -->
<style name="VerySmallFont">
<includeStyle name="DefaultFont"/>
<property name="font-size">-2pt</property>
</style>
<!-- A small font -->
<style name="SmallFont">
<includeStyle name="DefaultFont"/>
<property name="font-size">-1pt</property>
</style>
<!-- A medium font - just slightly bigger than default -->
<style name="MediumFont">
<includeStyle name="DefaultFont"/>
<property name="font-size">+1pt</property>
</style>
<!-- A large font -->
<style name="LargeFont">
<includeStyle name="DefaultFont"/>
<property name="font-size">+4pt</property>
</style>
<!-- A very large font -->
<style name="VeryLargeFont">
<includeStyle name="DefaultFont"/>
<property name="font-size">+6pt</property>
</style>
These font size definitions take advantage of an XML Style Sheet Language
feature which allows font size properties to be specified relative to
another font size value. Each of these styles includes the default font
size, by using the <includeStyle>
element to include the DefaultFont style, and then specifies a point
size increment or decrement relative to the default size. By using this
technique, blaf.xss makes it possible to change all font sizes with a
single override of the DefaultFont style. All other sizes used by blaf.xss
are computed relative to this size.
If you examine blaf.xss you may notice that the DefaultFont style is actually defined a second time:
<!-- Use "relative" font sizes on Windows IE -->
<styleSheet platforms="windows" browsers="ie" versions="5">
<!-- Override the default font sizes to use "scalable" size units -->
<!-- The default font -->
<style name="DefaultFont">
<property name="font-size">x-small</property>
</style>
</styleSheet>
This is an example of an environment-specific style sheet. This style sheet overrides the default value of the default font size specifically for the Windows IE 5 browser. The reason that blaf.xss defines this IE-specific style sheet is to take advantage of some IE-specific functionality. In particular, IE provides a text zooming feature which allows the user to scale text to a larger or smaller size, via the View->Text Size menu. Unfortunately, this functionality does not work with sizes specified in point units. It does, however, work with the sizes specified using the CSS "absolute size" keywords. So, for IE 5, we explicitly choose to use the "x-small" keyword for our default font size. By default, text rendered using this size is the same size as 10 point text. But this size can be scaled, so the end user is free to pick a larger or smaller size depending on their preference.
One implication of this IE 5 optimization is that in order for you to change the default font size for IE 5, you must define an equivalent environment-specific override. This is because the generic style sheet (with no attributes) that we defined above does not take precedence over the Windows IE 5 style sheet that contains the font size override. So, to change the default font size for your IE 5 users, you must define a second style sheet, using the same attributes as the Windows IE 5 style sheet defined in blaf.xss. For example, the following style sheet changes the default font size on Windows IE 5 to 12 points:
<styleSheet platforms="windows" browsers="ie" versions="5">
<!-- Change the default font size on IE 5 to 12pt -->
<style name="DefaultFont">
<property name="font-size">12pt</property>
</style>
</styleSheet>
Of course, by using point units, this style sheet disables IE's text scaling capability. So, perhaps a better choice would be to pick one of the CSS absolute size keywords (for example "small", "medium", etc...) for your Windows IE 5-specific style sheet.
Perhaps even more than fonts, customers of UIX-based applications are likely to want to customize the colors used by the Browser Look And Feel. The Browser Look And Feel makes use of four colors that are potential candidates for customization:
This is the color used for almost all text. The default text foreground color is black.
This is the background color used for almost all content. The default text background color is white.
This is the blue color which appears throughout the Browser Look And Feel user interface. The core background color is used as the background color for the selected link in the level one tab bar, as well as for the background color of the global header and footer. Additionally, the Browser Look And Feel derives a color ramp which includes lighter and darker shades based on the core background color. For example, the light blue foreground color for the selected link in the level one tab bar is derived from the core background color. The colors used for headers, the selected global button, as well as several other Browser Look And Feel components are also derived from the core background color.
This is the tan color which appears throughout the Browser Look And Feel user interface. For example, the accent background color is used as the background color for the unselected links in the level one tab bar, as well as for the background color of the level three side navigation component. As with the core background color, the Browser Look And Feel derives a color ramp which includes lighter and darker shades of the accent background color. For example, the dark brown foreground color used for hypertext links is derived from the accent color. The lighter yellow colors used for content containers and action button backgrounds are also derived from the accent color.
As is the case with fonts, blaf.xss takes advantage of Ocelot's style include functionality to share a common set of color-related named styles. Although practically every style defined in blaf.xss contains color information, the Browser Look And Feel colors can be customized by overriding the following four named styles:
<style name="TextForeground">
<property name="color">#000000</property>
</style>
<style name="TextBackground">
<property name="background-color">#ffffff</property>
</style>
<style name="DarkBackground">
<property name="background-color">#336699</property>
</style>
<style name="DarkAccentBackground">
<property name="background-color">#cccc99</property>
</style>
The "DarkBackground" and "DarkAccentBackground" styles define the primary color in the core color ramp and accent background ramp respectively. Other styles for lighter/darker shades are automatically derived based on these colors.
When selecting customized colors for the Browser Look And Feel, customers should try to maintain the contrasts between the text foreground/background colors, as well as between the core and accent colors. In general, colors from the web safe color palette should be used, as these colors have the most consistent results across the widest range of browsers and platforms. The web safe color palette is a set of 216 colors, where each color component (red, green, blue) is a multiple of 51 (0, 51, 102, 153, 204, or 255) or #33 for hexadecimal values (#00, #33, #66, #99, #cc, #ff). When selecting a customized core background color or accent background color, customers should take into account the fact that the Browser Look And Feel derives lighter and darker shades. As such, selecting very dark or very light values can result in a loss in distinction between various darker or lighter shades.
Although the appearance of the Browser Look And Feel can be customized to meet the user interface requirements of a particular deployment, many times this type of customer-specific customization is not sufficient. Many applications need to support user interface personalization, where the end user is allowed to specify preferred fonts, colors, etc... So, for example, rather than having a single font size for all users of a particular site, a user should be able to specify a preferred font size which is used when the user visits the site. Requiring the use of a separate XSS document for each end user would be a very tedious solution. Instead, the styles used by Browser Look And Feel can be dynamically customized via the Ocelot UserStyleSheet API.
The Ocelot UserStyleSheet class defines a set of styles which are merged with styles defined by the XSS document at render time. When UserStyleSheet styles are merged with XSS styles, the styles defined by the UserStyleSheet take precedence. As a result, when a UserStyleSheet containing user-specific style preferences is applied to an XSS document, the generated CSS file contains user-specific style definitions. Thus, personalizing the Browser Look And Feel becomes a matter of creating the appropriate UserStyleSheet instances based on user preferences and applying these UserStyleSheets when rendering a UIX-based page.
When creating a UserStyleSheet instance,
three pieces of information are specified:
a Dictionary of selector-based
Style objects, a
Dictionary of named
Style objects, and a unique id for the
style sheet. The Style interface is used
to describe a single style, which is defined in terms of a set of
style properties. Ocelot provides a single Style
implementation, the CSSStyle. The id is a
string which uniquely identifies the styles defined by a particular
UserStyleSheet. The id is embedded in the generated CSS
file name. As such, the id should be relatively short and preferably
should only contain ASCII characters. The id may be derived from the
end user's name/id, may be a integer-based count of the number of
unique UserStyleSheets defined by the system,
or may be a short description of the styles defined by the
UserStyleSheet, such as "14pt" or "14pt-Arial".
Note, however, that any single id must only correspond to a single set of
styles.
The following sample code shows how to create a
UserStyleSheet which can be used to modify
the default font family style:
// First, create a Style for the new font. We use the Ocelot CSSStyle class
CSSStyle style = new CSSStyle();
// Specify a new default font-family
style.setProperty("font-family", "serif");
// Store the Style in a Dictionary, hashed by name - "DefaultFontFamily".
// We use oracle.cabo.share.collection.ArrayMap for the Dictionary.
ArrayMap map = new ArrayMap(1);
map.put("DefaultFontFamily", style);
// Now, we can create the UserStyleSheet
UserStyleSheet styleSheet = new UserStyleSheet(
"serif", // The style sheet id - we just use the font family name
null, // The selector-based styles - we don't specify any
map // Our named styles
);
Once the UserStyleSheet has been created, it
can be applied in one of two ways. The easier way to apply a
UserStyleSheet is to set the
UserStyleSheet as a property on the UIX Components
RenderingContext using
StyleConstants.OCELOT_NAMESPACE and
StyleConstants.USER_STYLE_SHEET_PROPERTY as the namespace
and name of the property. Although this approach is easy to implement,
it does have one drawback. The UserStyleSheet will not
be applied to any contents rendered via UIX Components's own JSPs, such as the
DateFieldBean's calendar dialog.
In order to apply a UserStyleSheet to all
contents, including those rendered by UIX Components's JSPs, the
UserStyleSheet must be specified using the
Configuration.USER_STYLE_SHEET property
on a registered Configuration instance.
Note, however, since Configuration objects
are generally used to represent global configuration information, the
preferred approach is to use a Customization
object to specify render-specific configuration properties.
Customization objects are
Configuration objects which wrap other
Configuration objects, while allowing
certain properties to be overridden for a particular request, without
modifying the underlying Configuration
object. LIke any Configuration objects,
Customization objects must be registered
by name via Configuration.register().
Unlike other Configuration objects, which
generally exist for the lifetime of the application,
Customization
objects are meant to be shorter lived. That is,
Customization objects should only exist
while the user session for which they are being applied is active. Once
the user session expires, the Customization
object must be unregistered by calling the
Configuration.unregister() method. Typically,
Customization objects are unregistered in
response to an
HttpSessionBindingListener.valueUnbound()
event. Failure to unregister Customization
objects causes the Customization object and
all of its contents (such as the UserStyleSheet
object) to be leaked.
Although it is possible to customize font styles by explicitly creating
a UserStyleSheet instance with the necessary
Style objects, UIX provides convenience methods
which simplify the font personalization process. The
BlafStyleUtils.getFontStyles() method (in the
oracle.cabo.style.laf.browser package)
takes a font family name and a base font size and returns a
UserStyleSheet which contains the necessary
styles. The id for the UserStyleSheet is
automatically determined based on the specified properties.
When requesting a UserStyleSheet
with the getFontStyles() method,
it is possible to indicate that either the font family or the
font size should use the default value. In this case, the value
specified in the underlying XSS document is left unchanged. Also,
it is possible to specify that either value should not be specified
at all, by using the BlafStyleUtils.NO_FONT_FAMILY
BlafStyleUtils.NO_FONT_SIZE. In this case,
the font family or font size properties do not appear at all in the
generated CSS document. The ability to remove the font family
from the CSS style sheet can be useful for international users, who may
be better off letting the browser determine the best font to use for
localized data. Not specifying a font size can be beneficial for low
vision users, who may prefer to control the font size by other browser-specific
means.
UIX also provides a convenience method for creating a
UserStyleSheet for personalized colors:
BlafStyleUtils.getColorStyles().
getColorStyles() takes four
java.awt.Color objects and returns the appropriate
UserStyleSheet. The four colors are: the
text foreground color, the text background color, the dark core color and
the dark accent color. All other color shades used by the Browser Look
And Feel are automatically derived based on these four colors.
In order to specify both personalized fonts and personalized colors,
the UserStyleSheets returned from
getFontStyles() and
getColorStyles() can be combined into
a single UserStyleSheet using the
two-argument UserStyleSheet constructor.
The combined UserStyleSheet can then be
specified at render time via the
StyleConstants.USER_STYLE_SHEET_PROPERTY
or the Configuration.USER_STYLE_SHEET
property.
Although the UserStyleSheet API is extremely
flexible and allows for a wide range of user-specific customizations,
there are some drawbacks to this flexibility. Each new personalization
requires both a new style sheet, as well as a number of new images
which match the current colors and fonts. Unfortunately, the
image and style sheet generation capabilities which are provided with
UIX Dynamic Images and UIX Styles do not currently support automatic
cache pruning. So, once an image or style sheet is generated,
it remains on the cache until it is explicitly removed by the system
administrator. This means that sites which offer a wide range of
personalizations to a large user base may run into resource constraints
as the number of generated style sheets/images grows.
Future versions of UIX will likely solve this problem by supporting automatic pruning of obsolete resources. This will allow old images or style sheets to be temporarily removed when resource usage is high. In the meantime, one solution is for applications to offer a limited set of possible personalizations. For example, although it is desirable to allow end users to choose any colors, this can result in a large number of images being created for each unique set of colors. Instead, a compromise solution would be to allow users to choose from a set of predefined color schemes. Although future versions of UIX should make such limitations unnecessary, for now it is important to take resource usage into considering when designing your application's personalization features.
-->