JBoss.orgCommunity Documentation
Develop applications using RichFaces 4
Copyright ©
Abstract
Read this book for a comprehensive guide to getting started and working with RichFaces 4. It includes details of the architecture, the framework's use in different applications, and skinning implementations.
- 1. Introduction
- 2. Getting started with RichFaces
- 3. RichFaces overview
- 4. Basic concepts
- 5. Advanced features
- 6. Skinning and theming
- A. Style classes and skin parameters
- B. Migration Notes
- C. Revision History
The RichFaces framework is a rich component library for JavaServer Faces (JSF). The framework extends the Ajax capabilities of JSF with advanced features for the development of enterprise web applications.
RichFaces leverages several parts of the JSF 2 framework including the lifecycle, validation, conversion facilities, and management of static and dynamic resources. The RichFaces framework includes components with built-in Ajax support and a customizable look-and-feel that can be incorporated into JSF applications.
RichFaces provides a number of advantages for enterprise web application development:
- Create complex application views using out-of-the-box components. The RichFaces user interface (UI) library contains components for adding rich interactive features to JSF applications. It extends the RichFaces framework to include a large set of Ajax-enabled components that come with extensive skinning support. Additionally, the RichFaces framework is designed to be used seamlessly with other 3d-party libraries on the same page, so you have more options for developing applications.
- Write your own customized rich components with built-in Ajax support. The Component Development Kit (CDK), used for the RichFaces UI library creation, includes a code-generation facility and a templating facility using XHTML (extended hyper-text markup language) syntax.
- Generate binary resources on the fly. Extensions to JSF 2 resource-handling facilities can generate images, sounds, Microsoft Excel spreadsheets, and more during run-time.
- Create a modern rich user-interface with skinning technology. RichFaces provides a skinning feature that allows you to define and manage different color schemes and other parameters of the look and feel. It is possible to access the skin parameters from page code during run-time. RichFaces comes packaged with a number of skins to get you started, but you can also easily create your own customized skins too.
Follow the instructions in this chapter to configure the RichFaces framework and get started with application development.
If you have existing projects that use a previous version of RichFaces, refer to the RichFaces Migration Guide .
The minimum technical requirements needed to get started with RichFaces are outlined below.
- Java Development Kit (JDK) 6 or higher
- An application server compliant with Java Platform, Enterprise Edition 6 (JEE6), such as JBoss EAP 6™, WildFly™ or a servlet container coupled with a JSF implementation, such as Apache Tomcat + Mojarra 2.x.
- A compliant web browser, (see the section on Section 3.1.2, “Client requirements” for further details)
The RichFaces library is distributed across three jars providing all the components and services of the RichFaces framework.
RichFaces Library
-
richfaces-core.jar -
richfaces-a4j.jar -
richfaces-rich.jar
The framework depends on both mandatory and optional third-party dependencies. Some of the framework services are only enabled when the optional libraries are present.
Note that these dependencies may further depend on their own runtime dependencies.
Mandatory third-party dependencies
-
Java Server Faces 2.x implementation
-
javax.faces.jar(version2.1.28or higher) -
or
myfaces-impl.jar(version2.1.10or higher)
-
-
Google Guava
-
guava.jar(version18.0)
-
-
CSS Parser
-
cssparser.jar(version0.9.14)
-
-
Simple API for CSS
-
sac.jar(version1.3)
-
Optional third-party dependencies
-
Bean validation (JSR-303) integration for client-side validation (JSR-303 API and Implementation)
-
validation-api.jar(version1.0.0.GA) -
hibernate-validator.jar(version [code]+4.3.2.Final)
-
-
Push transport library - Atmosphere (without dependencies)
-
atmosphere-runtime.jar(version2.2.3)(selected compatibility modules
atmosphere-compat-*.jarmay be necessary)
-
-
Push JMS integration (JMS API and Implementation)
-
jms.jar(version1.1) -
hornetq-jms.jar(version2.2.7.Finalor higher)
-
-
Push CDI integration (CDI API and Implementation)
-
cdi-api.jar(version1.0-SP4) -
javax.inject.jar(version1) -
jsr-250-api.jar(version1.0) -
weld-servlet.jar(version2.2.6.Final)
-
-
Extended caching (EhCache)
-
ehcache.jar(version2.8.3)
-
Dependencies for servlet containers
Some of the dependencies are part of the Java EE 6 specification and thus it is not necessary to include them in projects running on Java EE applications servers. It is still necessary to include them when using servlet containers.
This does not apply to dependencies on the Servlet API: the JSP API and the EL API. These APIs are integral parts of both application servers and servlet containers.
RichFaces applications can be developed using a range of tools, including integrated development environments (IDEs). This chapter covers only two such environments in detail:
- JBoss Developer Studio™, as described in Section 2.4, “Creating a project with JBoss Developer Studio”.
- Maven™, as described in Section 2.5, “Creating a project with Maven”.
Other development environments such as Idea™ or NetBeans™ could also be used for RichFaces development, but such usage is not detailed in this book.
Follow the instructions in this section to set up a project with the RichFaces framework and begin building applications.
-
Download the RichFaces archive
Download RichFaces from the JBoss RichFaces Downloads area at http://www.jboss.org/richfaces/download.html. The binary files (available as a
.ziparchive) contain the following:- compiled, ready-to-use Java Archives (JAR files) of the RichFaces library
- library source JAR files
- documentation, including Java documentation and JavaScript documentation
- archetypes
- example source code
-
Unzip the archive
Create a new directory named
RichFaces, then unzip the archive that contains the binaries into this new directory.
Follow the procedure in this section to create a new RichFaces application with JBoss Developer Studio™. Ensure you are using the latest version of JBoss Developer Studio™ to take advantage of the latest feautures and stability improvements.
-
Create a new project
Create a new project based on the JSF 2 environment using the RichFaces 4 template. In JBoss Developer Studio™, select → from the menu. Name the project, select JSF 2 from the JSF Environment drop-down box, and click the button to create the project.
If necessary, update the JSF 2 JAR files to the latest versions.
-
Add the RichFaces libraries to the project
Add the RichFaces libraries and their mandatory dependencies to the project. Copy them from the location where you unzipped the RichFaces archive to the
WebContent/WEB-INF/lib/directory of your project in JBoss Developer Studio. -
The RichFaces tag libraries must be referenced on each XHTML page in your project:
<ui:composition xmlns:rich="http://richfaces.org/rich">
<ui:composition xmlns:a4j="http://richfaces.org/a4j">
...
</ui:composition>
You are now ready to begin developing your RichFaces application. RichFaces components can be dragged and dropped from the JBoss Developer Studio™ RichFaces palette into your application’s XHTML pages.
Apache Maven™ is a build automation and project management tool for Java projects. Follow the instructions in this section to create a Maven™ project for RichFaces™.
Maven™ can be downloaded and installed from Apache’s website at http://maven.apache.org/download.html. Due to the use of dependency importing, Maven™ version 3.0.4 or above is required.
Once Maven™ has been installed, no further configuration is required to begin building Maven projects.
A Maven archetype is a template for creating projects. Maven™ uses an archetype to generate a directory structure and files for a particular project, as well as creating pom.xml files that contain build instructions.
The RichFaces distribution includes a Maven archetype named richfaces-archetype-simpleapp for generating the basic structure and requirements of a RichFaces application project. Maven can obtain the archetype from maven central at http://search.maven.org. The archetype is also included with the RichFaces distribution in the archetypes directory. Follow the procedure in this section to generate a new Maven-based RichFaces project using the archetype.
-
Generate the project from the archetype
The project can be generated with the
richfaces-archetype-simpleapparchetype. Create a new directory for your project, then run the following Maven command in the directory:mvn archetype:generate -DarchetypeGroupId=org.richfaces.archetypes -DarchetypeArtifactId=richfaces-archetype-simpleapp -DarchetypeVersion=4.5.12.Final -DgroupId=org.docs.richfaces -DartifactId=new_project
The following parameters can be used to customize your project:
- -DgroupId
- Defines the package for the Managed Beans
- -DartifactId
-
Defines the name of the project
The command generates a new RichFaces project with the following structure:
new_project ├── pom.xml ├── readme.txt └── src └── main ├── java │ └── org │ └── docs │ └── richfaces │ └── RichBean.java └── webapp ├── index.xhtml ├── templates │ └── template.xhtml └── WEB-INF ├── faces-config.xml └── web.xml
-
Add test dependencies (optional)
Your root directory of your project contains a project descriptor file:
pom.xml. If you wish to include modules for test-driven JSF development, add any dependencies for the tests to thepom.xmlfile.For testing the server-side part of your application, check out JBoss Arquillian project™.
If you want to test JSF from client’s perspective with ability to access state of JSF internals, use Arquillian Warp™.
For automation of client-side tests in real-browser, you may want to employ Arquillian Graphene™ and Arquillian Drone™ extensions.
-
Build the project
Build the project from the command line by entering the mvn install command.
The BUILD SUCCESSFUL message indicates the project has been assembled and is ready to import into an IDE (integrated development environment), such as JBoss Developer Studio™.
-
Import the project into an IDE
To import the project into Eclipse™ and JBoss Developer Studio™, open the importing wizard by choosing → from the menu.
-
Select the project
Select → as the import source and choose the directory with the
pom.xmlfile for your project.
-
Exporting from Maven
The ability to prepare the project for Eclipse and export it using Maven is deprecated in RichFaces 4.5.12.Final. The process does not support JBoss integration-specific features, such as JSF Facets.
Your project is now ready to use. Once components and functionality have been added, you can run the application on a server and access it through a web browser at the address http://localhost:8080/jsf-app/ (where jsf-app is the name of your project).
RichFaces can be added to existing JSF 2 projects by adding the new RichFaces libraries. Refer to Step 2 and Step 3 in Section 2.4, “Creating a project with JBoss Developer Studio” for details.
Application-level settings
In RichFaces 4, it is not necessary to add any extra settings to the web.xml or config.xml settings files to use the framework.
Read this chapter for technical details on the RichFaces framework.
RichFaces has been developed with an open architecture to be compatible with a wide variety of environments.
RichFaces 4 requires either of the following server technologies:
- An application server compliant with Java Platform, Enterprise Edition 6 (JEE6 or JEE6), such as JBoss EAP 6.2.3+™ or WildFly 8.0.0.Final+™.
- A major servlet container, such as Jetty 8™ or Apache Tomcat 7™.
Clients accessing RichFaces applications require a web browser. For a list of supported web browsers, refer to the browser compatibility matrix in the RichFaces wiki.
Developing applications with the RichFaces framework requires the Java Development Kit (JDK), an implementation of JavaServer Faces (JSF), and a development environment.
- Java Development Kit (JDK)
-
RichFaces supports the following JDK versions:
- JDK 1.6 and higher
- JavaServer Faces (JSF)
-
RichFaces supports the following JSF implementations and frameworks:
- MyFaces 2.x™
- Mojara 2.x™
- Development environment
-
RichFaces can be developed using most Java development environments. The following are recommended, and used for examples in this guide:
- JBoss Developer Studio 6.x™ and higher
- Maven 3.0.4™ and higher
The important elements of the RichFaces framework are as follows:
- Ajax Action Components
- Ajax Containers
- Ajax Output
- Skins and Theming
- RichFaces Ajax Extensions
Read this section for details on each element.
The RichFaces framework includes several Ajax Action Components and Submitting Bahaviors: <a4j:commandButton>, <a4j:commandLink>, <a4j:poll>, <a4j:ajax>, and more. Use Ajax Action Components to send Ajax requests from the client side.
AjaxContainer is an interface that marks part of the JSF tree that is decoded during an Ajax request. It only marks the JSF tree if the component or behavior sending the request does not explicitly specify an alternative. AjaxRegion is an implementation of this interface.
AjaxContainer is an interface that marks part of the JSF tree that will be updated and rendered on the client for every Ajax request. It only marks the JSF tree if the component or behavior sending the request does not explicitly turn off automatic updates.
RichFaces includes extensive support for application skinning. Skinning is a high-level extension to traditional CSS (Cascading Style Sheets) which allows the color scheme and appearance of an application to be easily managed. The skins simplify look-and-feel design by allowing multiple elements of the interface to be handled as manageable features, which have associated color palettes and styling. Application skins can additionally be changed on the fly during run-time, allowing user experiences to be personalized and customized.
For full details on skinning and how to create skins for the components in your application, refer to Chapter 6, Skinning and theming.
RichFaces 4 features full JSF 2 integration and uses standard web application technologies such as JavaScript, XML (Extensible Markup Language), and XHTML (Extensible Hypertext Markup Language).
JavaServer Faces 2 evaluates Ajax options, such as execute and render, while rendering a page. This allows any parameters to be sent directly from the client side.
RichFaces evaluates the options when the current request is sent. This increases both the security of the data and the convenience for evaluating parameters.
For example, binding Ajax options to Java Bean properties in RichFaces allows you to evaluate the options dynamically for the current request, such as defining additional zones to render. Parameters changed manually on the client side will not influence the request processing. With JSF 2, the options have evaluated during the previous page rendering would need to be used.
The following restrictions apply to applications implementing the RichFaces framework:
-
As with most Ajax frameworks, you should not attempt to append or delete elements on a page using RichFaces Ajax, but should instead replace them. As such, elements that are rendered conditionally should not be targeted in the
renderattributes for Ajax controls. For successful updates, an element with the same identifier as in the response must exist on the page. If it is necessary to append code to a page, include a placeholder for it (an empty element). -
JSF 2 does not allow resources such as JavaScript or Cascading Style Sheets (CSS) to be added if the element requiring the resource is not initially present in the JSF tree. As such, components added to the tree via Ajax must have any required resources already loaded. In RichFaces, any components added to the JSF tree should have components with corresponding resources included on the main page initially. To facilitate this, components can use the
rendered="false"setting to not be rendered on the page. -
JSF does render resource links (stylesheets, scripts) in order of occurence, thus if you add
<h:outputStylesheet>to the<h:head>section, JSF will render it before the RichFaces resource links (dependencies of RichFaces components). To be able to overwrite RichFaces stylesheets and re-use RichFaces JavaScript implementation, you need to render<h:outputStylesheet target="head">to the<h:body>section (safe solution is to place it on the end of the section; however to keep readability, you can use start of the section). - Switching RichFaces skins via Ajax during runtime should be avoided, as this requires all the stylesheets to be reloaded.
Read this chapter for the basic concepts of using RichFaces in conjunction with Ajax and JavaServer Faces.
Many of the tags in the r tag library are capable of sending Ajax requests from a JavaServer Faces (JSF) page.
-
The
<a4j:commandButton>and<a4j:commandLink>tags are used to send an Ajax request on theclickJavaScript event. -
The
<a4j:poll>tag is used to send an Ajax request periodically using a timer. -
The
<a4j:ajax>tag allows you to add Ajax functionality to standard JSF components and send Ajax request on a chosen JavaScript event, such askeyupormouseover, for example. -
Most components in the
rtag library have built-in Ajax support. Refer to the RichFaces Component Reference for details on the use of each component.
Use the execute attribute to specify which parts of the JSF tree to process during an Ajax request. The execute attribute can point to an id identifier of a specific component to process. Components can also be identified through the use of Expression Language (EL).
Alternatively, the execute attribute accepts the following keywords:
@all- Every component is processed.
@none- No components are processed.
@this-
The requesting component with the
executeattribute is processed. @form- The form that contains the requesting component is processed.
@region-
The region that contains the requesting component is processed. Use the
<a4j:region>component as a wrapper element to specify regions. Some components make use of additional keywords. These are detailed under the relevant component entry in the RichFaces Component Reference .
Use the render attribute to specify which components to render for an Ajax update. The render attribute can point to an id identifier of a specific component to update. Components can also be identified through the use of Expression Language (EL).
Alternatively, the render attribute accepts the following keywords:
@all- Every component is updated.
@none- No components are updated.
@this-
The requesting component with the
executeattribute is updated. @form- The form that contains the requesting component is updated.
@region-
The region that contains the requesting component is updated. Use the
<a4j:region>component as a wrapper element to specify regions.
Some components make use of additional keywords. These are detailed under the relevant component entry in the RichFaces Component Reference .
Use the <a4j:outputPanel> component with the ajaxRendered="true" setting to always update a section irrespective of the requesting component’s render attribute. The <rich:message> and <rich:messages> components are based on the <a4j:outputPanel> component, and as such will also always be updated. To override this behavior, use the limitRender="true" setting on the requesting component.
The RichFaces framework is made up of two tag libraries: the rich and a4j libraries. The a4j tag library includes both the low-level ajax functionality, while the rich tag library includes the high-level components for building web applications. This allows developers to make use of custom Ajax behavior with existing componentsas well as leverage the many ready-made, self-contained components. These components don’t require additional configuration in order to send requests or update.
For details on the use of the various components, refer to RichFaces Component Reference .
Read this chapter for details on some of the advanced features and configuration possibilities for the RichFaces framework.
JavaServer Faces (JSF) is the Java-based web application framework upon which the RichFaces framework has been built. RichFaces is now integrated with JSF 2, which features several improvements to the framework.
- The standard display technology used by JSF 1 was JavaServer Pages (JSP). With JSF 2, the standard display technology has been changed to Facelets, which is a more powerful and more efficient View Declaration Language (VLD) than JSP.
RichFaces allows standard handlers to be defined for processing different application exceptions. Custom JavaScript can be executed when these exceptions occur.
JSF provides a global onError handler on the client. The handler provides the relevant error code and other associated data. The RichFaces Ajax components provide the error attribute if extra functionality needs to be defined.
Additional processing is available through a number of components, such as the following:
-
The
<a4j:status>component has an additional error state. -
The
<a4j:queue>component can be used to process errors.
RichFaces provides a number of advanced functions, such as managing user roles and identifying elements. Refer to the Functions chapter in the RichFaces Component Reference for further details.
The RichFaces improves a standard JSF resource handling in order to achieve following features:
- resource optimization - serves optimized component resource dependencies (JavaScript, CSS)
- resource mapping - re-routes resource requests (maps an one resource to an another resource)
For leveraging RichFaces resource loading improvements, the ResourceServlet needs to be registered.
ResourceServlet is automatically registered in the Servlet 3.0 and higher environments.
In the Servlet 2.5 and lower environments, it is necessary to register the ResourceServlet manually in the WEB-INF/web.xml configuration file:
<servlet>
<servlet-name>Resource Servlet</servlet-name>
<servlet-class>org.richfaces.webapp.ResourceServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Resource Servlet</servlet-name>
<url-pattern>/org.richfaces.resources/*</url-pattern>
</servlet-mapping>
The resource optimization feature provides optimized component dependencies - JavaScript, CSS - which are compressed and aggregated to resource packages.
The loading of compressed resource packages may lead into significant client performance boost, since many small files are aggregated into one big file - the number of HTTP connections necessary to download application resources is significantly decreased.
Example 5.1. Enabling resource optimization
To enable the resource optimization, add a following configuration to web.xml:
<context-param>
<param-name>org.richfaces.resourceOptimization.enabled</param-name>
<param-value>true</param-value>
</context-param>
Example 5.2. Resource optimization in development JSF project stage
Resource optimization is influenced by the project stage:
- resources are not compressed in the development stage and during unit-testing to enable client-side debugging
- resources are compressed in the production stage and during a system-testing to minimize network bandwidth
Switch to the development project stage during a development:
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
The resource mapping feature maps an existing JSF resource (determined by library and name) to a another resource.
This feature can help to solve the following cases:
- providing alternative versions of JSF resources
- map several JSF resources to one
- using external resources
- moving resources to servers serving static content
Configuring the resource mapping means adding new records to the class-path file META-INF/richfaces/static-resource-mappings.properties.
Each line in the configuration file represents one relocation.
A following sample shows a JSF resource with the name resourceLibrary:resourceName relocated to a resource anotherResourceLibrary:anotherResourceName:
resourceLibrary\:resourceName=anotherResourceLibrary/anotherResourceName
Mapping resource name to relative URL
The definition above contains a JSF resource name on the left side of the expression and a relative path on the right side.
The expression on the right side represents a path relative to a JSF resource root, thus resource path anotherResourceLibrary/anotherResourceName actually maps to a JSF resource with name anotherResourceLibrary:anotherResourceName.
Additional mapping files
It is possible to define additional resource mapping configuration files by using a contextual parameter identifying the class-path locations where the files reside: org.richfaces.resourceMapping.mappingFile (a comma-separated list of the class-path files).
Example 5.3. Providing alternative file
All requests for jquery.js are served as requests for jquery-alternative-version.js:
jquery.js=jquery-alternative-version.js
Example 5.4. Mapping several resources to one
Both some:jquery.js and another:jquery.js are mapped to final:jquery.js:
some\:jquery.js=final/jquery.js another\:jquery.js=final/jquery.js
Example 5.5. Using external resources
Mappings with a resource path starting with http:// or https:// are served as absolute resource locations:
A following sample instructs to load jquery.js from CDN:
jquery.js=http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js
Read this chapter for a guide to skinning and theming RichFaces applications, including how to implement themes, and details on customizing and extending skins.
Application skins are used with the RichFaces framework to change the appearance of an application through setting the colors and decoration of controls and components. Typically the appearance of web applications is handled through the CSS (Cascading Style Sheet) files associated with the application, but skinning allows the settings in a CSS file to be abstracted and easily edited. Skins consist of a small, generalized set of font and color parameters that can be applied to multiple different styles. This avoids repetitive coding and duplication in CSS files. CSS files are not completely replaced: skins work as a high-level extension to standard CSS.
Each skin has a set of skin-parameters, which are used to define the theme palette and other elements of the user interface. These parameters work together with regular CSS declarations, and can be referred to from within CSS using JavaServer Faces Expression Language (EL).
The skinning feature of RichFaces also allows skins to be changed at runtime, so users can personalize an application’s appearance on the fly.
RichFaces includes a number of predefined skins. These skins can be used in RichFaces web applications by specifying the skin name in the org.richfaces.skin context parameter in the web.xml settings file. The predefined skins are as follows:
-
DEFAULT -
plain, which contains no skin parameters and is intended for embedding RichFaces components into existing projects with their own styles. -
emeraldTown -
blueSky -
wine -
japanCherry -
ruby -
classic -
deepMarine
To add one of these skins to your application, add the org.richfaces.SKIN context parameter to the web.xml configuration file:
<context-param>
<param-name>org.richfaces.skin</param-name>
<param-value>skin_name</param-value>
</context-param>
RichFaces skins are implemented using the following three-level scheme:
- Component stylesheets
- Stylesheets are provided for each component. CSS style parameters map to skin parameters defined in the skin property file. This mapping is accomplished through the use of ECSS files. Refer to Section 6.3.3, “ECSS files” for details on ECSS files.
- Skin property files
-
Skin property files map skin parameters to constant styles. Skin properties are defined in
skin.propertiesfiles. Refer to Section 6.3.1, “Skin parameter tables” for a listing of the skin parameters used in a typical skin. - Custom style classes
-
Individual components can use the
styleClassattribute to redefine specific elements. These components then use the styles defined in a CSS file instead of the standard look for components as defined by the ECSS stylesheets.
Table 6.1, “Parameter settings for the blueSky skin” lists the default values for the parameter settings in the blueSky skin. These values are all listed in the blueSky.skin.properties file, which can be customized and extended as described in Section 6.4, “Customizing skins”.
Table 6.1. Parameter settings for the blueSky skin
| Parameter name | Default value |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Support for round borders in your skins is available via the panelBorderRadius skin parameter. The value of this parameter maps to the CSS 3 border-radius property. This CSS 3 property is ignored in older browsers, and the skin gracefully degrades to square corners.
Units of the panelBorderRadius skin parameter must be either px (pixels). or % (a percentage).
RichFaces uses ECSS files to add extra functionality to the skinning process. ECSS files are CSS files which use Expression Language (EL) to connect styles with skin properties.
Example 6.1. ECSS style mappings
The ECSS code for the <rich:panel> component contains styles for the panel and its body:
.rf-p{
background-color:'#{a4jSkin.generalBackgroundColor}';
color:'#{a4jSkin.panelBorderColor}';
border-width:1px;
border-style:solid;
padding:1px;
}
.rf-p-b{
font-size:'#{a4jSkin.generalSizeFont}';
color:'#{a4jSkin.generalTextColor}';
font-family:'#{a4jSkin.generalFamilyFont}';
padding:10px;
}
.rf-pdefines the panel styles-
-
The
background-colorCSS property maps to thegeneralBackgroundColorskin parameter. -
The
colorCSS property maps to thepanelBorderColorskin parameter.
-
The
.rf-p-bdefines the panel body styles-
-
The
font-familyCSS property maps to thegeneralFamilyFontskin parameter. -
The
font-sizeCSS property maps to thegeneralSizeFontskin parameter. -
The
colorCSS property maps to thegeneralTextColorskin parameter.
-
The
Skins in RichFaces can be customized on each of the three levels:
- Skin property files
-
Application interfaces can be modified by altering the values of skin parameters in the skin itself. Edit the constant values defined in the
skin.propertiesfile to change the style of every component mapped to that skin property. - Component stylesheets
- Mappings and other style attributes listed in a component’s ECSS file can be edited. Edit the ECSS file to change the styles of all components of that type.
- Custom components style classes
-
Individual components can use the
styleClassattribute to use a unique style class. Add the new style class to the application CSS and reference it from an individual component with thestyleClassattribute. - Overwriting stylesheets in application
-
You can load custom stylesheets using
<h:outputStylesheet>which rewrites of extends styles defined for style classes of components.
Customizing skins by rewriting/extending component style classes
If you want to extend/overwrite style sheet definitions with own stylesheets, make sure you place definitions to be rendered in right order of occurence (see Restrictions section for details).
Example 6.2. Simple skinning example
Using any component, such as a panel, without specifying a styleClass will use the default skin parameters for that component.
<rich:panel>This is a panel without a header</rich:panel>
When rendered for display, the panel consists of two HTML elements: a wrapper <div> element and a <div> element for the body of the panel. The wrapper element for a panel without a specified styleClass is rendered as follows:
<div id="..." class="rf-p">
<div id="..." class="rf-p-b">
This is a panel without a header
</div>
</div>
To customize the panel appearance according to the three-level scheme, adjust the styles according to the following approach:
-
Change the definitions for the
generalBackgroundColororpanelBorderColorparameters in the skin. This will cause all panels in the application to change to the new settings. -
Redefine the
rf-pclass in the application CSS. This will also cause all panels in the application to change to the new settings, though the skin itself has not been altered. Any properties not mapped to skin parameters should be redefined in this way. -
Specify a different
styleClassattribute to style the individual component. If astyleClassattribute is used, the specified style class is applied to the component, which could extend or override the default styles.<rich:panel styleClass="customClass">...</rich:panel>
The
customClassstyle is added to the CSS, and is applied to the component when it is rendered for display:<div class="rf-p customClass">
...
</div>
-
Create the skin file
The name of the skin file should follow the format
new_skin_name.skin.propertiesand is placed in either theMETA-INF/skins/directory or the classpath directory of your project. -
Define the skin constants
-
Define all the skin constants
Add skin parameter constants and values to the file. All the skin parameters listed in Table 6.1, “Parameter settings for the blueSky skin” should be included in the skin file, with settings relevant to your new skin.
Example 6.3.
blueSky.skin.propertiesfileOpen the
blueSky.skin.propertiesfile from the/META-INF/skinsdirectory in therichfaces-core-{version}.jarpackage. The file lists all the skin parameter constants shown in Table 6.1, “Parameter settings for the blueSky skin”.You can use the
blueSky.skin.propertiesfile as a template for your new skin.
-
Extend a base skin
Instead of redefining an entire new skin, your skin can use an existing skin as a base on which to build new parameters. Specify a base skin by using the
baseSkinparameter in the skin file, as shown in Example 6.4, “Using a base skin”.Example 6.4. Using a base skin
This example takes the
blueSkyskin as a base and only changes thegeneralSizeFontparameter.baseSkin=blueSky generalSizeFont=12px
-
-
Reference the skin definition
Add a skin definition
<context-param>to theweb.xmlsettings file of your application:<context-param>
<param-name>org.richfaces.skin</param-name>
<param-value>new_skin_name</param-value>
</context-param>
To allow users to change skins at runtime, use a managed bean to access the skin.
-
Create the skin bean
The skin bean is a simple interface to manage the skin:
public class SkinBean {
private String skin;
public String getSkin() {
return skin;
}
public void setSkin(String skin) {
this.skin = skin;
}
} -
Reference the skin bean
Add the
@ManagedBeanand@SessionScopedreferences to the class.-
Alternatively, use EL (Expression Language) to reference the skin bean from the
web.xmlsettings file.<context-param>
<param-name>org.richfaces.skin</param-name>
<param-value>#{skinBean.skin}</param-value>
</context-param>
-
-
Set initial skin
The application needs an initial skin to display before the user chooses an alternative skin. Specify the skin in your class with
@ManagedProperty.@ManagedProperty(value="blueSky")
private String skin;-
Alternatively, specify the initial skin in the
web.xmlconfiguration file.<managed-bean>
<managed-bean-name>skinBean</managed-bean-name>
<managed-bean-class>SkinBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<property-name>skin</property-name>
<value>blueSky</value>
</managed-property>
</managed-bean>
-
Standard HTML controls used alongside RichFaces components are also themed to create a cohesive user interface.
The skinning style properties are automatically applied to controls based on their element names and attribute types. If the HTML elements are referenced in the standard skin stylesheets, the controls will be styled according to the mapped skin properties.
Standard HTML controls are skinned in this way by default. To override this behavior and prevent the RichFaces skins from being applied to the standard HTML controls, set the org.richfaces.enableControlSkinning context parameter in the web.xml configuration file to false:
<context-param>
<param-name>org.richfaces.enableControlSkinning</param-name>
<param-value>false</param-value>
</context-param>
The skinning style properties can be determined through a separate CSS class. This method is not available by default, but is enabled through the org.richfaces.enableControlSkinningClasses context parameter in the web.xml configuration file:
<context-param>
<param-name>org.richfaces.enableControlSkinningClasses</param-name>
<param-value>true</param-value>
</context-param>
When enabled, a stylesheet with predefined classes offers a special CSS class named rfs-ctn. Reference the rfs-ctn class from any container element (such as a <div> element) to skin all the standard HTML controls in the container.
Standard HTML controls can also be specifically defined in the CSS. Refer to the /META-INF/resources/org.richfaces/skinning_both.ecss file in the richfaces-core-{version}.jar package for examples of specially-defined CSS classes with skin parameters for HTML controls.
Each of the RichFaces™ components are listed below, along with their style classes and skin parameters. For further details on each component, refer to the relevant section in the RichFaces Component Reference .
Table A.1. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.2. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
| |
|
|
|
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.3. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
|
|
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
Table A.4. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
Table A.5. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
|
|
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
Table A.6. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.7. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
Table A.8. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
Table A.9. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
|
|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.10. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
|
|
|
|
|
|
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
|
|
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.11. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
|
|
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
Table A.12. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
|
|
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
Table A.13. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
|
|
Table A.14. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
|
|
|
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.15. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.16. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
Table A.17. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
| |
|
|
|
| No skin parameters. | |
|
|
|
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
| |
Table A.18. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
Table A.19. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
Table A.20. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
| |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
Table A.21. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
Table A.22. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
|
Table A.23. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
| |
|
|
|
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
|
|
|
|
|
|
Table A.24. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
|
|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.25. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
|
|
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
| No skin parameters. | |
Table A.26. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
|
|
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
| No skin parameters. | |
Table A.27. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
| No skin parameters. | |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
|
|
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
|
|
|
| No skin parameters. | |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
| No skin parameters. | |
Table A.28. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
| |
|
| |
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.29. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No skin parameters. | |
Table A.30. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| No skin parameters. | |
Table A.31. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
| |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.32. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
|
|
|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.33. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
Table A.34. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
|
|
|
|
| |
|
|
|
|
| |
|
| |
Table A.35. Style classes (selectors) and corresponding skin parameters
| Class (selector) | Skin Parameters | Mapped CSS properties |
|---|---|---|
| No skin parameters. | |
| No skin parameters. | |
| No skin parameters. | |
|
|
|
|
| |
|
| |
Style classes (selectors)
.rf-ind- This class defines styles for the drag indicator.
.rf-ind-drag.accept- This class defines styles for the indicator when it is over an acceptable drop target.
.rf-ind-drag.reject- This class defines styles for the indicator when it is over an unacceptable drop target.
.rf-ind-drag.default- This class defines styles for the indicator when it is being dragged, and is not over any drop targets.
This section of the guide will track any breaking changes introduced in new releases, and identify any steps required to accommodate those changes in your application.
The <rich:extendedDataTable> now has built-in sorting and filtering controls. If you have existing <rich:extendedDataTable> with custom sort and/or filter controls, you will want to disable the built-in sort and/or filter controls. This can be done either on a column-by-column basis, or for all columns in your applications.
For details on disabling the built-in sort and filter controls, refer to sections "External filter controls" and "External sort controls" in the RichFaces Component Reference.
Prior to version 4.3.0.Final, the message summary and details of the <rich:notifyMessage> and <rich:notifyMessages> components were not escaped. In the 4.3.0.Final release, an attribute escape was added with a default value true.