14 Changing the Appearance of Your Application

This chapter describes how to change the default appearance of your application by changing style properties, using ADF skins, and internationalizing the application.

This chapter includes the following sections:

Section 14.1, "Introduction to Changing ADF Faces Components"
Section 14.2, "Changing the Style Properties of a Component"
Section 14.3, "Using Skins to Change the Look and Feel"
Section 14.4, "Internationalizing Your Application"

14.1 Introduction to Changing ADF Faces Components

ADF Faces components delegate the functionality of the component to a component class, and the display of the component to a renderer. Renderers determine the different ways a component can be displayed on a client, or how to display the component on different clients. The component's tag used on a page determines the unique combination of a component class and a renderer. By default, all tags for ADF Faces combine the associated component class with an HTML renderer, and are part of the HTML render kit. For example, the command button and the command link components are both UICommand components; however, they use different renderers. You can create your own custom renderers; it is beyond the scope of this document to explain how to create JSF renderers or custom components.

You cannot customize the ADF Faces renderers. However, you can customize how components display using skins. By default, applications created using ADF Faces components use the Oracle skin. However, the SRDemo sample application uses a custom skin. Skins are an easy way to globally style an application. You can create your own skin to change the colors, fonts, and even the location of portions of ADF Faces components, by setting styles for components in one CSS file. You then configure the application to use the skin when displaying the application. Included with ADF Faces are HTML render kits for display on both desktop and PDA.

If you don't wish to change the entire look of an application, you can choose to change the inline styles for a component on a page. You can also programatically set styles conditionally. For example, you may want to display text red, only under certain conditions.

In addition to changing the appearance of your application, you can also internationalize your application, allowing users in different locales to view text strings in the language to which their browser is set.

Many ADF Faces components include text strings, and the components handle the translation of those strings for you automatically. Any text that is part of the component displays in the language of the user's browser.

You need to translate only the text you add to the application. You can also change other locale-specific properties, such as text direction and currency code.

Read this chapter to understand:

How to use inline styles to change a component's appearance
How to conditionally set a style property on a component
How to create a custom skin
How to internationalize your application

14.2 Changing the Style Properties of a Component

ADF Faces components use the CSS style properties, based on the Cascading Style Sheet specification. Cascading style sheets contain rules, composed of selectors and declarations that define how styles will be applied. These are then interpreted by the browser and override the browser's default settings. It is beyond the scope of this document to explain the concepts of CSS. Visit the W3C web site (http://www.w3c.org/) for extensive information on style sheets, including the official specification.

You can change a style property to alter a component's appearance. ADF Faces components use both inline style properties that can set individual attributes (such as font-size and font-color), as well as style classes used to group a set of inline styles. For example, the style class .AFFieldText sets all properties for the text displayed in an inputText component.

14.2.1 How to Set a Component's Style Attributes

You can set inline styles or you can declare a style class for an ADF Faces component on a page.

To set the style:

In the Structure window, select the component you wish to style.
In the Property Inspector, expand the Core node. This node contains all the attributes related to how the component displays.
To set a style class for the component, click in the StyleClass field and click the ellipses (...) button. In the StyleClass dialog, enter a style class for use on this component. For additional help in using the dialog, click Help.
To set an inline attribute, expand the InlineStyle node. Click in the field for the attribute to set, and use the dropdown menu to choose a value.

You can also use EL expressions for the InlineStyle attribute itself to conditionally set inline style attributes. For example, in the SRSearch page of the SRDemo application, the date in the Assigned Date column displays red if a service request has not yet been assigned. Example 14-1 shows the code on the JSF page for the outputText component.
Example 14-1 EL Expression Used to Set a Style Attribute
```
<af:outputText value="#{row.assignedDate eq  
    null?res['srsearch.highlightUnassigned']:row.assignedDate}"
              inlineStyle="#{row.assignedDate eq null?'color:rgb(255,0,0);':''}"/>
```

14.2.2 What Happens When You Format Text

As Example 14-1 shows, when you use the Property Inspector to set a style, JDeveloper adds the corresponding code for the component to the JSF page.

14.3 Using Skins to Change the Look and Feel

Skins allow you to globally change the appearance of ADF Faces components within an application. A skin is a global style sheet that only needs to be set in one place for the entire application. Instead of having to style each component, or having to insert a style sheet on each page, you can create one skin for the entire application. Every component will automatically use the styles as described by the skin. The application developer does not need to add any code, and any changes to the skin will be picked up at runtime, no change to code is needed.

Skins are also based on the Cascading Style Sheet specification. By default, ADF Faces applications use the Oracle skin. Components in the visual editor as well as in the web page display using the settings for this skin. Figure 14-1 shows the SRList page with the Oracle skin applied.

Note:

The syntax in a skin style sheet is based on the CSS3 specification. However, many browsers do not yet adhere to this version. At runtime, ADF Faces converts the CSS to the CSS2 specification.

Figure 14-1 The SRList Page Using the Oracle Skin

ADF Faces also provides two other skins. The Minimal skin provides some formatting, as shown in Figure 14-2. Notice that almost everything except the graphic for the page has changed, including the colors, the shapes of the buttons, and where the copyright information displays.

Figure 14-2 The SRList Page Using the Minimal Skin

The SRList page with minimal formatting.

The third skin provided by ADF Faces is the Simple skin. This skin contains almost no special formatting, as shown in Figure 14-3.

Figure 14-3 The SRList Page Using the Simple Skin

The SRDemo application uses a custom skin created just for that application, as shown in Figure 14-4.

Figure 14-4 The SRList Page Using the Custom SRDemo Skin

In addition to using a CSS file to determine the styles, skins also use a resource bundle to determine the text within a component. For example, the word "Select" in the selection column shown in Figure 14-4 is determined using the skin's resource bundle. All the included skins use the same resource bundle.

14.3.1 How to Use Skins

Custom skins extend the Simple skin. To create a custom skin, you declare selectors in a style sheet that override the selectors in the Simple skin's style sheet. Any selectors that you choose not to override will continue to use the style as defined in the Simple skin. Once you create your skin's style sheet, you need to register it as a valid skin in the application, and then configure the application to use the skin.

The selectors used by the simple skin are listed in the "Selectors for Skinning ADF Faces Components" topic in JDeveloper's online help. It is located in the Reference > Oracle ADF Faces book. This document shows selectors broken down into three sections: global selectors, button selectors, and component-level selectors. Global selectors determine the style properties for multiple components. Examples include the default font family and background colors. Button selectors are used to style all buttons in the application.

Note:

Button selectors style all buttons in the application. You cannot define separate selectors for different buttons. For example, the af:commandButton and af:goButton components will display the same.

Component selectors determine the styles for specific components or portions of a component. Icon selectors denote where the icon can be found.

Within each section are the selectors that can be styled. There are three types of selectors: standard selectors, selectors with pseudo elements, and selectors that use the alias pseudo classes. Standard selectors are those that directly represent an element that can have styles applied to it. For example af|body represents the af:body component. You can set CSS styles, properties, and icons for this type of element.

Pseudo elements are used to denote a specific area of component that can have styles applied. Pseudo elements are denoted by a double colon followed by the portion of the component the selector represents. For example, af|column::cell-text provides the styles and properties for the text in a cell of a column.

The alias pseudo class is used for a selector that sets styles for more than one component or more than one portion of a component. For example, the .AFMenuBarItem:alias selector defines skin properties that are shared by all af:menuBar items. Any properties defined in this alias are included in the af|menuBar::enabled and af|menuBar::selected style classes. If you change the .AFMenuBarItem:alias style, you will affect the af|menuBar::enabled and af|menuBar::selected selectors. You can also create your own pseudo classes for inclusion in other selectors.

You can create multiple skins. For example, you might create one skin for the version of an application for the web, and another for when the application runs on a PDA. Or you can change the skin based on the locale set on the current user's browser. Additionally, you can configure a component, for example a selectOneChoice component, to allow a user to switch between skins.

The text used in a skin is defined in a resource bundle. As with the selectors for the Simple skin, you can override the text by creating a custom resource bundle and declaring only the text you want to change. The keys for the text that you can override are documented in the "Reference: Keys for Resource Bundle Used by Skins" topic of the JDeveloper online help. Once you create your custom resource bundle, you register it with the skin.

Note:

ADF Faces components provide automatic translation. The resource bundle used for the components' skin is translated into 28 languages. If a user sets the browser to use the German (Germany) language, any text contained within the components will automatically display in German. For this reason, if you create a resource bundle for a custom skin, you must also create localized versions of that bundle for any other languages the application supports. For more information about Internationalization, see Section 14.4, "Internationalizing Your Application".

14.3.1.1 Creating a Custom Skin

You create a custom skin by extending the Simple skin and overriding the selectors. You then need to register the skin with the application.

To create a custom skin:

Review your pages using the Simple skin to determine what you would like to change. For procedures on changing the skin, see Section 14.3.1.2, "Configuring an Application to Use a Skin".
In JDeveloper, create a CSS file:
1. Right-click the project that contains the code for the user interface and choose New to open the New Gallery.
2. In the New Gallery, expand the Web Tier node and select HTML.
3. Double-click CSS File.
4. Complete the Create Cascading Style Sheet dialog. Click Help for help regarding this dialog.
Refer to the "Selectors for Skinning ADF Faces Components" topic in JDeveloper's online help. It is located in the Reference > Oracle ADF Faces book. Add any selectors that you wish to override to your CSS file and set the properties as needed. You can set any properties as specified by the CSS specification.

If you are overriding a selector for an icon, use a content relative path for the URL to the icon image (that is, start with a leading forward slash), and do not use quotes. Also, you must include the width and the height for the icon. Example 14-2 shows a selector for an icon.
Example 14-2 Selector for an Icon
```
.AFButtonDisabledStartIcon:alias
 {
      content:url(/skins/srdemo/images/btnDisabledStart.gif);
      width:7px; height:18px
 }
```
Icons and buttons can both use the rtl pseudo class. This defines an icon or button for use when the application displays in right-to-left mode. Example 14-3 shows the rtl psuedo class used for an icon.
Example 14-3 Icon Selector Using the rtl Psuedo Class
```
.AFButtonDisabledStartIcon:alias:rtl
 {
      content:url(/skins/srdemo/images/btnDisabledStartRtl.gif);
      width:7px; height:18px
 }
```
Tip:
Overriding an alias will likely change the appearance of more than one component. Be sure to carefully read the reference document so that you understand what you may be changing.
Y ou can create your own alias classes that you can then include on other selectors. To do so:
1. Create a selector class for the alias. For example, the SRDemo skin has an alias used to set the color of a link when a cursor hovers over it:
```
.MyLinkHoverColor:alias {color: #CC6633;}
```
2. To include the alias in another selector, add a pseudo element to an existing selector to create a new selector, and then reference the alias using the -ora-rule-ref:selector property.
  
  For example, the SRDemo skin created a new selector for the af|menuBar::enabled-link selector in order to style the hover color, and then referenced the custom alias, as shown in Example 14-4.
  Example 14-4 Referencing a Custom Alias in a New Selector
```
af|menuBar::enabled-link:hover
{
  -ora-rule-ref:selector(".MyLinkHoverColor:alias");
}
```
Save the file to a directory.

Once you've created the CSS, you need to register the skin and then configure the application to use the skin.

To create a custom bundle for the skin:

Review the "Reference: Keys for Resource Bundle Used by Skins" topic of the JDeveloper online help and your pages using the Simple skin to determine what text you would like to change. For procedures on changing the skin to the Simple skin, see Section 14.3.1.2, "Configuring an Application to Use a Skin".
In JDeveloper, create a resource bundle. It must be of type java.util.ResourceBundle. For detailed instructions, see Section 14.4.1, "How to Internationalize an Application".
Add any keys to your bundle that you wish to override and set the text as needed.

Tip:
If you internationalize your application, you must also create localized versions of this resource bundle. For more information and procedures, see Section 14.4.1, "How to Internationalize an Application".

To register a custom skin and bundle:

If one does not yet exist, create an adf-faces-skins.xml file (the file is located in the <view_project_name>/WEB-INF directory). This file will be used to declare each skin accessible to the application.
1. Right-click your view project and choose New to open the New Gallery.
  
  The New Gallery launches. The file launches in the Source editor.
2. In the Categories tree on the left, select XML. If XML is not displayed, use the Filter By dropdown list at the top to select All Technologies.
3. In the Items list, select XML Document and click OK.
4. Name the file adf-faces-skins.xml, place it in the <view_project_name>/WEB-INF directory, and click OK.
5. Replace the generated code with the code shown in Example 14-5.
  Example 14-5 Default Code for an adf-faces-skins.xml File
```
<?xml version="1.0" encoding="ISO-8859-1"?>
<skins xmlns="http://xmlns.oracle.com/adf/view/faces/skin">
    
  <skin>

  </skin>
 
</skins>
```
Register the new skin by defining the following for the skin element:
- <id>: This value will be used if you want to reference your skin in an EL expression. For example, if you want to have different skins for different locales, you can create an EL expression that will select the correct skin based on its ID.
- <family>: You configure an application to use a particular family of skins. Doing so allows you to group skins together for an application, based on the render kit used.
- <render-kit-id>: This value determines which render kit to use for the skin. You can enter one of the following:
  - oracle.adf.desktop: The skin will automatically be used when the application is rendered on a desktop.
  - oracle.adf.pda: The skin will be used when rendered on a PDA.
- <style-sheet-name>: This is the fully qualified path to the custom CSS file.
- <bundle-name>: The resource bundle created for the skin. If you did not create a custom bundle, then you do not need to declare this element.
  
  Note:
  If you have created localized versions of the resource bundle, you only need to register the base resource bundle.
Example 14-6 shows the entry in the adf-faces-skins.xml file for the SRDemo skin.
Example 14-6 Skins Entry for the SRDemo Skin in the adf-faces-skins.xml File
```
<skin>
  <id>
    srdemo.desktop
  </id>
  <family>
    srdemo
  </family>
  <render-kit-id>
    oracle.adf.desktop
  </render-kit-id>
  <style-sheet-name>
    skins/srdemo/srdemo.css
  </style-sheet-name>
</skin>
```

14.3.1.2 Configuring an Application to Use a Skin

You set an element in the adf-faces-config.xml file that determines which skin to use, and if necessary, under what conditions.

To configure an application to use a skin:

Open the adf-faces-config.xml file.
Replace the <skin-family> value with the family name for the skin you wish to use. Example 14-7 shows the configuration to use the srdemo skin family.
Example 14-7 Configuration to Use a Skin Family
```
<adf-faces-config xmlns="http://xmlns.oracle.com/adf/view/faces/config">
  <skin-family>srdemo</skin-family>
</adf-faces-config>
```
To conditionally set the value, enter an EL expression that can be evaluated to determine the skin to display.

For example, if you want to use the German skin when the user's browser is set to the German locale, and use the English skin otherwise, you would have the following entry in the adf-faces-config.xml file:
```
<skin-family>#{facesContext.viewRoot.locale.language=='de' ? 'german' : 'english'}</skin-family>
```
To configure a component to dynamically change the skin, you must first configure the component on the JSF page to set a value in scope that can later be evaluated by the configuration file. You then configure the skin family in the adf-faces-config file to be dynamically set by that value.
1. Open the JSF page that contains the component that will be used to set the skin family.
2. Configure the component to set the skin family in sessionScope. Example 14-8 shows a selectOneChoice component that takes its selected value, and sets it as the value for the skinFamily attribute in sessionScope.
  Example 14-8 Using a Component to Set the Skin Family
```
<af:selectOneChoice label="Select Skin" 
                    value="#{sessionScope.skinFamily}"
                    onchange="form.submit();">
  <af:selectItem label="Simple" value="simple"/>
  <af:selectItem label="Minimal" value="minimal"/>
  <af:selectItem label="Oracle" value="oracle"/> 
  <af:selectItem label="SRDemo" value="srdemo"/> 
</af:selectOneChoice>
```
  The onchange event handler will perform a form POST when ever a skin is selected in the selectOneChoice component. Alternative you can add a command button to the page that will re-submit the page. Every time there is a POST the EL expression will be evaluated, and if there is a new value redraw the page with the new skin.
3. In the adf-faces-config file, use an EL expression to dynamically evaluate the skin family:
```
<skin-family>#{sessionScope.skinFamily}</skin-family>
```

14.4 Internationalizing Your Application

When your application will be viewed by users in more than one country, you can configure your application to use different locales so that it displays the correct language for the language setting of a user's browser. For example, if you know your application will be viewed in Germany, you can localize your application so that when a user's browser is set to use the German language, text strings in the application will appear in German.

ADF Faces components provide automatic translation. The resource bundle used for the components' skin (which determines look and feel, as well as the text within the component) is translated into 28 languages. If a user sets the browser to use the German (Germany) language, any text contained within the components will automatically display in German. For more information on skins and this resource bundle, see Section 14.3.1, "How to Use Skins". For a complete list of all text included in ADF Faces components, see the "Reference: Keys for Resource Bundle Used by Skins" topic of the JDeveloper online help.

For any text you add to the application, you need to provide a resource bundle that holds the actual text, and you need to load that bundle into the page using the JSF loadBundle tag. Then, instead of directly entering the text on the JSF page or entering the text as a value for the Text attribute of a component, you bind that attribute to a key in the resource bundle. You then create a version of the resource bundle for each locale.

Note:

Any text retrieved from the database is not translated. This document covers how to localize static text, not text that is stored in the database.

Figure 14-5 shows the SRList page from the SRDemo application in a browser set to use the English (United States) language.

Figure 14-5 The SRList Page in English

The SRList page displays all text in English by default.

Although the title of this page is "My Service Requests," instead of having "My Service Requests" as the value for the title attribute of the PanelPage component, the value is bound to a key in the UIResources resource bundle. The UIResources resource bundle is loaded into the page using the loadBundle tag, as shown in Example 14-9. The resource bundle is given a variable name (in this case res) that can then be used in EL expressions. The title attribute of the panelPage component is then bound to the srlist.pageTitle key in that resource bundle.

Example 14-9 Resource Bundles Used in a JSF Page

<f:view>
  <f:loadBundle basename="oracle.srdemo.view.resources.UIResources"
                  var="res"/>
  <af:document title="#{res['srdemo.browserTitle']}"
               initialFocusId="viewButton">
    <af:form>
      <af:panelPage title="#{res['srlist.pageTitle']}">

The UIResources resource bundle has an entry in the English language for all static text displayed on each page in the SRDemo application, as well as text for messages and global text, such as generic labels. Example 14-10 shows the keys for the SRList page.

Example 14-10 Resource Bundle Keys for the SRList Page Displayed in English

#SRList Screen
srlist.pageTitle=My Service Requests
srlist.menubar.openLink=Open Requests
srlist.menubar.pendingLink=Requests Awaiting Customer
srlist.menubar.closedLink=Closed Requests
srlist.menubar.allRequests=All Requests
srlist.menubar.newLink=Create New Service Request
srlist.selectAnd=Select and 
srlist.buttonbar.view=View
srlist.buttonbar.edit=Edit

Figure 14-6 also shows the SRList page, but with the browser set to use the German (Germany) locale.

Figure 14-6 The SRList Page in German

SRList page using the German locale displays text in German

Note:

The column headings were not translated because the values are bound to the label property of the binding object. This value is set as a control hint in the entities structure XML file. Whenever any values are set for the label, a resource bundle is automatically created. To translate these, you must create localized versions of these resource bundles.

Example 14-11 shows the resource bundle version for the German (Germany) language, UIResource_de. Note that there is not an entry for the selection facet's title, yet it was translated from "Select" to "Auswahlen" automatically. That is because this text is part of the ADF Faces table component's selection facet.

Example 14-11 Resource Bundle Keys for the SRList Page Displayed in German

#SRList Screen
srlist.pageTitle=Meine Service Anfragen
srlist.menubar.openLink=Offene Anfragen
srlist.menubar.pendingLink=Anfrage wartet auf Kunden
srlist.menubar.closedLink=Geschlossene Anfragen
srlist.menubar.allRequests=Alle Anfragen
srlist.menubar.newLink=Erstelle neue Service Anfrage
srlist.selectAnd=Kommentare wählen und
srlist.buttonbar.view=Ansich

The resource bundles for the application can be either Java classes or property files. The abstract class ResourceBundle has two subclasses: PropertyResourceBundle and ListResourceBundle. A PropertyResourceBundle is stored in a property file, which is a plain-text file containing translatable text. Property files can contain values only for String objects. If you need to store other types of objects, you must use a ListResourceBundle instead. The contents of a property file must be encoded as ISO 8859-1. Any characters not in that character set must be stored as escaped Unicode.

To add support for an additional locale, you simply replace the values for the keys with localized values and save the property file appending a language code (mandatory), and an optional country code and variant as identifiers to the name, for example, UIResources_de.properties. The SRDemo application uses property files.

Note:

Property files must contain characters in the IS0 8859-1 character set. If you need to use other characters, use a ListResourceBundle class instead.

All non-8859-1 character sets must be converted to escaped UTF-8 characters, or they will not display correctly.

The ListResourceBundle class manages resources in a name, value array. Each ListResourceBundle class is contained within a Java class file. You can store any locale-specific object in a ListResourceBundle class. To add support for an additional locale, you subclass the base class, save it to a file with an locale / language extension, translate it, and compile it into a class file.

The ResourceBundle class is flexible. If you first put your locale-specific String objects in a PropertyResourceBundle file, you can still move them to a ListResourceBundle class later. There is no impact on your code, since any call to find your key will look in both the ListResourceBundle class as well as the PropertyResourceBundle file.

The precedence order is class before properties. So if a key exists for the same language in both a class file and in a property file, the value in the class file will be the value presented to the user. Additionally, the search algorithm for determining which bundle to load is as follows:

(baseclass)+(specific language)+(specific country)+(specific variant)
(baseclass)+(specific language)+(specific country)
(baseclass)+(specific language)
(baseclass)+(default language)+(default country)+(default variant)
(baseclass)+(default language)+(default country)
(baseclass)+(default language)

For example, if a user's browser is set to the German (Germany) locale and the default locale of the application is US English, the application will attempt to find the closest match, looking in the following order:

de_Germany
de
en_US
en
The base class bundle

Tip:

The getBundle method used to load the bundle looks for the default locale classes before it returns the base class bundle. If it fails to find a match, it throws a MissingResourceException error. A base class with no suffixes should always exist in order to avoid throwing this exception

14.4.1 How to Internationalize an Application

To internationalize your application, you need to do the following:

Tip:

These procedures will allow the application to display the correct language based on the browser settings of the user. You may also want to create your application in a way that allows the user to manually set the locale they wish to use. The current locale is stored in the viewRoot of FacesContext.

Create a base resource bundle that contains all the text strings that are not part of the components themselves. This bundle should be in the default language of the application.
Tips:
- Instead of creating one resource bundle for the entire application, you can create multiple resource bundles. For example, in a JSF application, you must register the resource bundle that holds error messages with the application in the faces-config.xml file. For this reason, you may want to create a separate bundle for messages.
- Create your resource bundle as a Java class instead of a property file if you need to include values for objects other than Strings, or if you need slightly enhanced performance.
- The getBundle method used to load the bundle looks for the default locale classes before it returns the base class bundle. However if it fails to find a match, it throws a MissingResourceException error. A base class with no suffixes should always exist in order to avoid throwing this exception
Use the base resource bundle on the JSF pages by loading the bundle and then binding component attributes to keys in the bundle.
Create a localized resource bundle for each locale supported by the application.
Register the locales with the application.
Register the bundle used for application messages.

Note:

If you use a custom skin and have created a custom resource bundle for the skin, you must also create localized versions of that resource bundle. Similarly if your application uses control hints to set any text, you must create localized versions of the generated resource bundles for that text.

Detailed procedures for each step follow.

To create a resource bundle as a property file:

In JDeveloper, create a new simple file.
1. In the Application Navigator, right-click where you want the file to be placed and choose New to open the New Gallery.
  
  Note:
  If you are creating a localized version of the base resource bundle, save the file to the same directory as the base file.
2. In the Categories tree, select Simple Files, and in the Items list, select File.
3. Enter a name for the file, using the extension.properties.
  
  Note:
  If you are creating a localized version of a base resource bundle, you must append the ISO 639 lowercase language code to the name of the file. For example, the German version of the UIResources bundle is UIResources_de.properties. You can add the ISO 3166 uppercase country code (for example de_DE) if one language is used by more than one country. You can also add an optional non standard variant (for example, to provide platform or region information).
  If you are creating the base resource bundle, no codes should be appended.
Create a key and value for each string of static text for this bundle. The key is a unique identifier for the string. The value is the string of text in the language for the bundle. If you are creating a localized version of the base resource bundle, any key not found in this version will inherit the values from the base class.
Note:
All non-ASCII characters must be either UNICODE escaped or the encoding must be explicitly specified when compiling, for example:
```
javac -encoding ISO8859_5 UIResources_de.java
```
For example the key and value for the title of the SRList page is:
```
srlist.pageTitle=My Service Requests
```
Note:
All non-8859-1 character sets must be converted to escaped UTF-8 characters, or they will not display correctly.

To create a resource bundle as a Java Class:

In JDeveloper, create a new simple Java class:
- In the Application Navigator, right-click where you want the file to be placed and choose New to open the New Gallery.
  
  Note:
  If you are creating a localized version of the base resource bundle, this must reside in the same directory as the base file.
- In the Categories tree, select Simple Files, and in the Items list, select Java Class.
- Enter a name and package for the class. The class must extend java.util.ListResourceBundle.
  
  Note:
  If you are creating a localized version of a base resource bundle, you must append the ISO 639 lowercase language code to the name of the class. For example, the German version of the UIResources bundle might be UIResources_de.java. You can add the ISO 3166 uppercase country code (for example de_DE) if one language is used by more than one country. You can also add an optional non standard variant (for example, to provide platform or region information).
  If you are creating the base resource bundle, no codes should be appended.
Implement the getContents() method, which simply returns an array of key-value pairs. Create the array of keys for the bundle with the appropriate values. Example 14-12 shows a sample base resource bundle java class.

Note:
Keys must be Strings. If you are creating a localized version of the base resource bundle, any key not found in this version will inherit the values from the base class.
Example 14-12 Base Resource Bundle Java Class
```
package sample;import java.util.ListResourceBundle;public class MyResources extends ListResourceBundle {  public Object[][] getContents() {    return contents;  }  static final Object[][] contents = {    {"button_Search", "Search"},    {"button_Reset", "Reset"},  };}
```

To use a base resource bundle on a page:

You need to load only the base resource bundle on the page. The application will automatically use the correct version based on the user's locale setting in their browser.

Set your page encoding and response encoding to be a superset of all supported languages. If no encoding is set, the page encoding defaults to the value of the response encoding set using the contentType attribute of the page directive. Example 14-13 shows the encoding for the SRList page.

Example 14-13 Page and Response Encoding

<?xml version='1.0' encoding='windows-1252'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
          xmlns:h="http://java.sun.com/jsf/html"
          xmlns:f="http://java.sun.com/jsf/core"
          xmlns:af="http://xmlns.oracle.com/adf/faces"
          xmlns:afc="http://xmlns.oracle.com/adf/faces/webcache">
  <jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
              doctype-system="http://www.w3.org/TR/html4/loose.dtd"
              doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
  <jsp:directive.page contentType="text/html;charset=UTF-8"/>
  <f:view>

Tip:

By default JDeveloper sets the page encoding to windows-1252. To set the default to a different page encoding:

From the menu, choose Tools > Preferences.
In the left-hand pane, select Environment if it is not already selected.
Set Encoding to the preferred default.

Load the base resource bundle onto the page using the loadBundle tag, as shown in Example 14-14. The basename attribute specifies the fully qualified name of the resource bundle to be loaded. This resource bundle should be the one created for the default language of the application. The var attribute specifies the name of a request scope attribute under which the resource bundle will be exposed as a Map, and will be used in the EL expressions that bind component attributes to a key in the resource bundle.
Example 14-14 The loadBundle Tag
```
<f:loadBundle basename="oracle.srdemo.view.resources.UIResources"
              var="res"/>
```
Bind all attributes that represent strings of static text displayed on the page to the appropriate key in the resource bundle, using the variable created in the previous step. Example 14-15 shows the code for the View button on the SRList page.
Example 14-15 Binding to a Resource Bundle
```
<af:commandButton text="#{res['srlist.buttonbar.view']}"
                  . . . />
```

To register locales:

Open the faces-config.xml file and select the Overview tab in the editor window. The faces-config.xml file is located in the <View_Project>/WEB-INF directory.
In the JSF Configuration Editor, select Application.
If not already displayed, click the Local Config's triangle to display the Default Locale and Supported Locales fields.
For Default Locale, enter the ISO locale identifier for the default language to be used by the application. This identifier should represent the language used in the base resource bundle.
Add additional supported locales by clicking New. Click Help or press F1 for additional help in registering the locales.

To register the message bundle:

Open the faces-config.xml file and click on the Overview tab in the editor window. The faces-config.xml file is located in the <View_Project>/WEB-INF directory.
In the window, select Application.
For Message Bundle, enter the fully qualified name of the base bundle that contains messages to be used by the application.

14.4.2 How to Configure Optional Localization Properties for ADF Faces

Along with providing text translation, ADF Faces also automatically provides other types of translation, such as text direction and currency codes. The application will automatically display appropriately based on the user's selected locale. However, you can also manually set the following localization settings for an application in the adf-faces-config.xml file.

<currency-code>: Defines the default ISO 4217 currency code used by oracle.adf.view.faces.converter.NumberConverter to format currency fields that do not specify a currency code in their own converter.
<number-grouping-separator>: Defines the separator used for groups of numbers (for example, a comma). ADF Faces automatically derives the separator from the current locale, but you can override this default by specifying a value in this element. If set, this value is used by oracle.adf.view.faces.converter.NumberConverter while it parses and formats.
<decimal-separator>: Defines the separator (for example, a period or a comma) used for the decimal point. ADF Faces automatically derives the separator from the current locale, but you can override this default by specifying a value in this element. If set, this value is used by oracle.adf.view.faces.converter.NumberConverter while it parses and formats.
<right-to-left>: ADF Faces automatically derives the rendering direction from the current locale, but you can explicitly set the default page rendering direction by using the values true or false.
<time-zone>: ADF Faces automatically uses the time zone used by the client browser. This value is used by oracle.adf.view.faces.converter.DateTimeConverter while it converts Strings to Date.

To configure optional localization properties:

Open the adf-faces-config.xml file. The file is located in the <View_Project>/WEB-INF directory.
From the Component Palette, drag the element you wish to add to the file into the Structure window. An empty element is added to the page.
Enter the desired value.

Example 14-16 shows a sample adf-faces-config.xml file with all the optional localization elements set.

Example 14-16 Configuring Currency Code and Separators for Numbers and Decimal Point

<!-- Set the currency code to US dollars. -->
<currency-code>USD</currency-code>

<!-- Set the number grouping separator to period for German -->
<!-- and comma for all other languages -->
<number-grouping-separator>
 #{view.locale.language=='de' ? '.' : ','}
</number-grouping-separator>

<!-- Set the decimal separator to comma for German -->
<!-- and period for all other languages -->
<decimal-separator>
 #{view.locale.language=='de' ? ',' : '.'}
</decimal-separator>

<!-- Render the page right-to-left for Arabic -->
<!-- and left-to-right for all other languages -->
<right-to-left>
 #{view.locale.language=='ar' ? 'true' : 'false'}
</right-to-left>

<!-- Set the time zone to Pacific Daylight Savings Time -->
<time-zone>PDT</time-zone>