Chapter 1. Introduction

RichFaces is an open source framework that adds Ajax capability into existing JSF applications without resorting to JavaScript.

RichFaces leverages JavaServer Faces framework including lifecycle, validation, conversion facilities and management of static and dynamic resources. RichFaces components with built-in Ajax support and a highly customizable look-and-feel can be easily incorporated into JSF applications.

RichFaces allows to:

Intensify the whole set of JSF benefits while working with Ajax. RichFaces is fully integrated into the JSF lifecycle. While other frameworks only give you access to the managed bean facility, RichFaces advantages the action and value change listeners, as well as invokes server-side validators and converters during the Ajax request-response cycle.

Add Ajax capability to the existing JSF applications. Framework provides two components libraries (Core Ajax and UI). The Core library sets Ajax functionality into existing pages, so there is no need to write any JavaScript code or to replace existing components with new Ajax ones. RichFaces enables page-wide Ajax support instead of the traditional component-wide support and it gives the opportunity to define the event on the page. An event invokes an Ajax request and areas of the page which become synchronized with the JSF Component Tree after changing the data on the server by Ajax request in accordance with events fired on the client.

Create quickly complex View basing on out of the box components. RichFaces UI library contains components for adding rich user interface features to JSF applications. It extends the RichFaces framework to include a large (and growing) set of powerful rich Ajax-enabled components that come with extensive skins support. In addition, RichFaces components are designed to be used seamlessly with other 3d-party component libraries on the same page, so you have more options for developing your applications.

Write your own custom rich components with built-in Ajax support. We're always working on improvement of Component Development Kit (CDK) that was used for RichFaces UI library creation. The CDK includes a code-generation facility and a templating facility using a JSP-like syntax. These capabilities help to avoid a routine process of a component creation. The component factory works like a well-oiled machine allowing the creation of first-class rich components with built-in Ajax functionality even more easily than the creation of simpler components by means of the traditional coding approach.

Package resources with application Java classes. In addition to its core, Ajax functionality of RichFaces provides an advanced support for the different resources management: pictures, JavaScript code, and CSS stylesheets. The resource framework makes possible to pack easily these resources into Jar files along with the code of your custom components.

Create a modern rich user interface look-and-feel with skins-based technology. RichFaces provides a skinnability feature that allows easily define and manage different color schemes and other parameters of the UI with the help of named skin parameters. Hence, it is possible to access the skin parameters from JSP code and the Java code (e.g. to adjust generated on-the-fly images based on the text parts of the UI). RichFaces comes with a number of predefined skins to get you started, but you can also easily create your own custom skins.

Test and create the components, actions, listeners, and pages at the same time. An automated testing facility is in our roadmap for the near future. This facility will generate test cases for your component as soon as you develop it. The testing framework will not just test the components, but also any other server-side or client-side functionality including JavaScript code. What is more, it will do all of this without deploying the test application into the Servlet container.

RichFaces UI components come ready to use out-of-the-box, so developers save their time and immediately gain the advantage of the mentioned above features in Web applications creation. As a result, usage experience can be faster and easily obtained.

This chapter describes all necessary actions and configurations that should be done
for plugging the RichFaces components into a JSF appplication. The description
relies on a simple JSF with RichFaces application creation process from
downloading the libraries to running the application in a browser. The process
of application creation described here is common and does not depend on used
IDE.

3.1. Downloading the RichFaces

The latest release of RichFaces components is available for download at
JBoss RichFaces Downloads area at JBoss community.
Binary files (uploaded there in *.bin.zip or
*.bin.tar.gz archives) contains compiled,
ready-to-use version of RichFaces with set of basic skins.

To start with RichFaces in computer file system create new folder with
name "RichFaces", download and unzip the archive with binaries there.

For those who want to download and compile the RichFaces by themselfs there is an article
at JBoss community that describes the
RichFaces repository's structure overview and
some aspects of working with it.

3.2. Simple JSF application with RichFaces

"RichFaces Greeter"—the simple application—is hello-world like
application but with one difference: the world of RichFaces will say
"Hello!" to user first.

Create standard JSF 1.2 project with all necessary libraries; name the project
"Greeter" and follow the decription.

3.2.1. Adding RichFaces libraries into the project

Go to the folder with unzipped earlier RichFaces binary files
and open lib folder. This folder contains three
*.jar files with API, UI and
implementation libraries. Copy that "jars" from
lib folder to WEB-INF/lib folder
of "Greeter" JSF application.

Important:

A JSF application with RichFaces
assumes that the following JARs are available in the project:
commons-beanutils-1.7.0.jar, commons-collections-3.2.jar, commons-digester-1.8.jar, commons-logging-1.0.4.jar, jhighlight-1.0.jar.

3.2.2. Registering RichFaces in web.xml

After RichFaces libraries where added into the project it is
necessary to register them in project web.xml
file. Add following lines in web.xml:

The application uses three RichFaces components:
<rich:panel> is used as visual container for information;
<a4j:commandButton> with built-in Ajax support allows rendering a greeting dynamically after a response comes back
and <a4j:form> helps the button to perform the action.

Note, that the RichFaces tag library should be declared on each
JSP page.

For Facelets you should add the following lines for tag
library declaration:

That's it. Run the application on server. Point your browser to index.jsp page in browser:
http://localhost:8080/Greeter/index.jsf

Figure 3.1. "RichFaces Greeter" application

3.3. Integration of RichFaces into Maven Project

In this section we will tell how you can create a simple JSF application with RichFaces using Maven.

In the first place you need to make sure that Maven is installed on you local machine. We will run the JSF application on Tomcat 6.0 server, so please download and install it if you haven't done already so.

Now we can move on to creating the application. To create the project structure and fill it with minimal content we will use the "maven-archetype-jsfwebapp" Maven archetype which is a part of RichFaces CDK.

The "maven-archetype-jsfwebapp" archetype and the project itself require extra repositories to be provided, namely "http://snapshots.jboss.org/maven2/" and "http://repository.jboss.com/maven2/".
The easiest way to make the repositories visible for Maven is to create a profile in "maven_installation_folder/conf/settings.xml" in <profiles> element. This is the content of the profile:

Now go to "jsf-app" folder, it contains a project descriptor(pom.xml). Open the project descriptor to edit and add dependencies to the <dependencies> element. Your <dependencies> element content should be the following:

The last three dependences add RichFaces libraries to the project. You can now build the project with the mvn install command.

When you see the "BUILD SUCCESSFUL" message, the project is assembled and can be imported to a IDE and run on the server.

The project can be built for Eclipse IDE with mvn eclipse:eclipse -Dwtpversion=2.0 command.

Then you can import the project into Eclipse. After importing to Eclipse open the "jsf-app/src/main/webapp/WEB-INF/web.xml" to configure it according to the listing in the Registering RichFaces in web.xml section of the guide.

The project is configured and now you can start using RichFaces. Open "jsf-app/src/main/webapp/pages/index.jsp" file and add the tag library declaration.

...<%@ tagliburi="http://richfaces.org/rich"prefix="rich"%>...

Add some RichFaces component to the "index.jsp" page, for instance <rich:calendar>. Your "index.jsp" page will look like this:

JBoss Developer Studio comes with a tight integration with RichFaces component framework.
Following links might be useful for those who already use this IDE and RichFaces for developing applications and those who wish to improve their development process:

"Rich Components" chapter
in "Getting Started with JBoss Developer Studio Guide" describes how to add RichFaces components into a CRUD application;

Chapter 4. Settings for different environments

RichFaces comes with support for all tags (components) included in the JavaServer
Faces specification. To add RichFaces capabilities to the existing JSF project
you should just put the RichFaces libraries into the lib folder of the project
and add filter mapping. The behavior of the existing project doesn't
change just because of RichFaces.

4.1. Web Application Descriptor Parameters

RichFaces doesn't require any parameters to be defined in your web.xml. But
the RichFaces parameters listed below may help with
development and may increase the flexibility of RichFaces usage.

Table 4.1. Initialization Parameters

Name

Default

Description

org.richfaces.SKIN

DEFAULT

Is a name of a skin used in an
application. It can be a
literal string with a skin
name, or the EL expression
(#{...})
pointed to a String property (skin
name) or a property of a
org.richfaces.framework.skin
type. Skin in last case, this
instance is used as a current
skin

Is an URL to an application or a
container log file (if
possible). If this parameter
is set, content from the given
URL is shown on a Debug error page in the iframe window

org.ajax4jsf.VIEW_HANDLERS

none

Is a comma-separated list of
custom ViewHandler instances for
inserting in chain. Handlers
are inserted BEFORE RichFaces
viewhandlers in the given
order. For example, in
facelets application this
parameter must contain
com.sun.facelets.FaceletViewHandler,
instead of declaration in
faces-config.xml

org.ajax4jsf.CONTROL_COMPONENTS

none

Is a comma-separated list of
names for a component as a
special control case, such as
messages bundle loader, alias
bean components, etc. Is a
type of component got by a
reflection from the static
field COMPONENT_TYPE. For components
with such types encode methods
always are called in rendering
Ajax responses, even if a
component isn't in an
updated part

org.ajax4jsf.ENCRYPT_RESOURCE_DATA

false

For generated resources, such as
encrypt generation data,
it's encoded in the
resource URL. For example, URL
for an image generated from
the mediaOutput component contains
a name of a generation method,
since for a hacker attack, it
is possible to create a
request for any JSF baked
beans or other attributes. To
prevent such attacks, set this
parameter to
"true" in
critical applications (works
with JRE > 1.4
)

org.ajax4jsf.ENCRYPT_PASSWORD

random

Is a password for encryption of
resources data. If
isn't set, a random
password is used

org.ajax4jsf.COMPRESS_SCRIPT

true

It doesn't allow
framework to reformat
JavaScript files (makes it
impossible to debug)

org.ajax4jsf.RESOURCE_URI_PREFIX

a4j

Defines prefix which is added to
all URIs of generated
resources. This prefix
designed to handle RichFaces
generated resources requests

org.ajax4jsf.GLOBAL_RESOURCE_URI_PREFIX

a4j/g

Defines prefix which is added to
URIs of global resources. This
prefix designed to handle
RichFaces generated resources
requests

org.ajax4jsf.SESSION_RESOURCE_URI_PREFIX

a4j/s

Defines prefix which is used for
session tracking for generated
resources. This prefix
designed to handle RichFaces
generated resources requests

org.ajax4jsf.DEFAULT_EXPIRE

86400

Defines in seconds how long
streamed back to browser
resources can be cached

org.ajax4jsf.SERIALIZE_SERVER_STATE

false

If enabled the component state
(not the tree) will be
serialized before being stored
in the session. This may be
desirable for applications
that may have issues with view
state being sensitive to model
changes. Instead of this
parameter can use
com.sun.faces.serializeServerState
and
org.apache.myfaces.SERIALIZE_STATE_IN_SESSION
parameters for
corresponding environments.

Note:

org.richfaces.SKIN is used in the same way as
org.ajax4jsf.SKIN

Table 4.2. org.ajax4jsf.Filter Initialization Parameters

Name

Default

Description

log4j-init-file

-

Is a path (relative to web
application context) to the log4j.xml configuration
file, it can be used to setup
per-application custom
logging

enable-cache

true

Enable caching of
framework-generated resources
(JavaScript, CSS, images,
etc.). For debug purposes
development custom JavaScript
or Style prevents to use old
cached data in a
browser

forcenotrf

true

Force parsing by a filter HTML syntax checker on
any JSF page. If
"false",
only Ajax responses are parsed
to syntax check and conversion
to well-formed XML. Setting to
"false"
improves performance, but can
provide visual effects on Ajax
updates

4.2. Sun JSF RI

RichFaces works with implementation of JSF (JSF 1.2_12)
and with most JSF component libraries without any
additional settings. For more information look at:

Additional information how to get ViewExpiredExceptions
when using RichFaces with JSF
1.2_12 you can find in RichFaces Cookbook article.

4.3. Apache MyFaces

RichFaces works with Apache MyFaces 1.2.5 version
including specific libraries like TOMAHAWK Sandbox and Trinidad (the
previous ADF Faces). However, there are some considerations to take
into account for configuring applications to work with
MyFaces and RichFaces.

Note:

There are some problems with different filters defined in the web.xml
file clashing. To avoid these problems, the RichFaces filter must be
the first one among other filters in the web.xml configuration file.

There's one more problem while using MyFaces +
Seam . If you use this combination you should use <a4j:page> inside <f:view> (right after it in your code) wrapping another content
inside your pages because of some problems in realization of <f:view> in myFaces.

The problem is to be overcome in the nearest future.

4.4. Facelets Support

A high-level support for Facelets is one of our main
support features. When working with RichFaces, there is no difference
what release of Facelets is used.

You should also take into account that some JSF frameworks such as
Facelets use their own
ViewHandler and need to have it first in the
chain of ViewHandlers and the RichFaces AjaxViewHandler is not an
exception. At first RichFaces installs its ViewHandler in any case, so
in case of two frameworks, for example RichFaces + Facelets, no
changes in settings are required. Although, when more then one
framework (except RichFaces) is used, it's possible to use
the VIEW_HANDLERS parameter defining these frameworks
view handlers according to its usage order in it. For example, the
declaration:

says that Facelets will officially be the first,
however AjaxViewHandler will be a little ahead
temporarily to do some small, but very important job.

Note:

In this case you don't have to define
FaceletViewHandler in the
WEB-INF/faces-config.xml.

4.5. JBoss Seam Support

RichFaces now works out-of-the-box with JBoss Seam
and Facelets running inside JBoss AS 4.0.4 and higher. There is no
more shared JAR files needed. You just have to package the RichFaces
library with your application.

This is because, EAServer calls servlet init() before the
ServletContextInitializer. Not an EAServer bug,
this is in Servlet 2.3 spec.

4.8. Oracle AS/OC4J

In order to deploy your project with RichFaces components to an
Oracle AS you just have to prevent the
application's class loader from importing the Oracle XML
parser. Use the following notation in
orion-application.xml :

5.1. Introduction

The framework is implemented as a component library which adds Ajax capability into
existing pages, so you don't need to write any JavaScript code or to replace
existing components with new Ajax widgets. RichFaces enables
page-wide Ajax support instead of the traditional component-wide support. Hence, you can
define the event on the page that invokes an Ajax request and the areas of the page that
should be synchronized with the JSF Component Tree after the Ajax request changes the
data on the server according to the events fired on the client.

Next Figure shows how it works:

Figure 5.1. Request Processing flow

RichFaces allows to define (by means of JSF tags) different parts
of a JSF page you wish to update with an Ajax request and provide a few options to send
Ajax requests to the server. Also JSF page doesn't change from a
"regular" JSF page and you don't need to write any JavaScript or
XMLHTTPRequest objects by hands, everything is done automatically.

5.2. RichFaces Architecture Overview

Next figure lists several important elements of the RichFaces
framework

Figure 5.2. Core Ajax component structure

Ajax Filter.

To get all benefits of RichFaces , you should register a
Filter in web.xml file of your application. The Filter recognizes multiple request
types. Necessary information about Filter configuration can be found in the "Filter configuration"
section. The sequence diagram on Figure 3 shows the difference in processing
of a "regular" JSF request and an Ajax request.

In the first case the whole JSF tree will be encoded, in the second one option it
depends on the "size" of the Ajax region. As you can see, in the second case
the filter parses the content of an Ajax response before sending it to the client side.

Have a look at the next picture to understand these two ways:

Figure 5.3. Request Processing sequence diagram

In both cases, the information about required static or dynamic resources that your
application requests is registered in the ResourseBuilder class.

When a request for a resource comes (Figure 4), the RichFaces filter checks the
Resource Cache for this resource and if it is there, the resource is sent to the client.
Otherwise, the filter searches for the resource among those that are registered by the
ResourceBuilder. If the resource is registered, the RichFaces filter will send a request
to the ResourceBuilder to create (deliver) the resource.

Next Figure shows the ways of resource request processing.

Figure 5.4. Resource request sequence diagram

AJAX Action Components

There are Ajax Action Components: <a4j:commandButton>, <a4j:commandLink>, <a4j:poll> and<a4j:support> and etc. You can use them to send Ajax requests from the client side.

AJAX Containers

AjaxContainer is an interface that describes an area on your JSF page that should
be decoded during an Ajax request. AjaxViewRoot and
AjaxRegion are implementations of this interface.

JavaScript Engine

RichFaces JavaScript Engine runs on the client-side. It knows
how to update different areas on your JSF page based on the information from the
Ajax response. Do not use this JavaScript code directly, as it is available
automatically.

5.3. Partial Rendering

RichFaces framework enhances the JSF framework with partial rendering of the components with Ajax capability enabled.
This means that only the part of the page that should be affected by some change is updated. Ajax capability of the components can be enabled by the "mode", "switchType" etc. set to "ajax".
This approach prevents multiple page refreshes, which minimized server load.

A good example that can illustrate this feature is rendering of the tabs of the <rich:tabPanel>.
By default the component updates the whole page to display the content of the tab which is clicked on, to enable partial rendering the "switchType" attribute set to "ajax" should be used.

5.4. RichFaces Integral Parts

For more information about framework and libraries loading see the following section
in the FAQ.

Note:

In order to prevent JavaScript versions conflict you should use only one version
of the framework or library. You could find more information about libraries
exclusion in the FAQ.

5.5. Limitations and Rules

In order to create RichFaces applications properly, keep the following points in
mind:

Any Ajax framework should not append or delete, but only replace elements on
the page. For successful updates, an element with the same ID as in the response
must exist on the page. If you'd like to append any code to a page, put in
a placeholder for it (any empty element). For the same reason, it's
recommended to place messages in the "AjaxOutput" component (as no messages is also a message).

Don't use <f:verbatim> for self-rendered containers, since this component is transient and
not saved in the tree.

Ajax requests are made by XMLHTTPRequest functions in XML format, but this
XML bypasses most validations and the corrections that might be made in a
browser. Thus, create only a strict standards-compliant code for HTML and XHTML,
without skipping any required elements or attributes. Any necessary XML
corrections are automatically made by the XML filter on the server, but
lot's of unexpected effects can be produced by an incorrect HTML code.

The RichFaces ViewHandler puts itself in front of the
Facelets ViewHandlers chain.

RichFaces components uses their own renderers. On the
Render Response Phase RichFaces framework makes a traversal
of the component tree, calls its own renderer and put the result into the Faces
Response.

5.6.1. Re-Rendering

Ajax attributes are common for Ajax components such as <a4j:support> , <a4j:commandButton> , <a4j:jsFunction> , <a4j:poll> , <a4j:push> and so on. Also, most RichFaces components with built-in Ajax support
have these attributes for a similar purpose. Ajax components attributes help
RichFaces to expose its features. Most of the attributes have default values. Thus,
you can start working with RichFaces without knowing the usage of these attribute.
However, their usage allows to tune the required Ajax behavior very smoothly.

"reRender" is a key attribute. The attribute allows to point to area(s) on a page
that should be updated as a response on Ajax interaction. The value of the
"reRender" attribute is an id of the JSF component or an id list.

The value of "reRender" attribute of the <a4j:commandButton> tag defines which part(s) of your page is (are) to be updated. In this
case, the only part of the page to update is the <h:panelGrid> tag because its ID value matches to the value of "reRender" attribute. As you see, it's not difficult to update multiple
elements on the page, only list their IDs as the value of "reRender" .

"reRender" uses UIComponent.findComponent() algorithm (with some additional
exceptions) to find the component in the component tree. As can you see, the
algorithm presumes several steps. Each other step is used if the previous step is
not successful. Therefore, you can define how fast the component is found mentioning
it more precisely. The following example shows the difference in approaches (both
buttons will work successfully):

It's also possible to use JSF EL expression as a value of the reRender
attribute. It might be a property of types Set, Collection, Array or simple String.
The EL for reRender is resolved right before the Render Response phase. Hence, you
can calculate what should be re-rendered on any previous phase during the Ajax
request processing.

Most common problem with using reRender is pointing it to the component that has
a "rendered" attribute. Note, that JSF does not mark the place in the browser DOM
where the outcome of the component should be placed in case the "rendered" condition returns false. Therefore, after the component becomes rendered
during the Ajax request, RichFaces delivers the rendered code to the client, but
does not update a page, because the place for update is unknown. You need to point
to one of the parent components that has no "rendered" attribute. As an alternative, you can wrap the component with <a4j:outputPanel>layout="none" .

"ajaxRendered" attribute of the <a4j:outputPanel> set to "true" allows to define the area of the page that will
be re-rendered even if it is not pointed in the reRender attribute explicitly. It
might be useful if you have an area on a page that should be updated as a response
on any Ajax request. For example, the following code allows to output error messages
regardless of what Ajax request causes the Validation phase failed.

"limitToList" attribute allows to dismiss the behavior of the <a4j:outputPanel>"ajaxRendered" attribute. limitToList = "true" means to update
only the area(s) that mentioned in the "reRender" attribute explicitly. All output panels with
ajaxRendered="true" is ignored. An example is placed
below:

5.6.2. Queue and Traffic Flood Protection

"eventsQueue" attribute defines the name of the queue that will be used to order
upcoming Ajax requests. By default, RichFaces does not queue Ajax requests. If
events are produced simultaneously, they will come to the server simultaneously. JSF
implementations (especially, the very first ones) does not guaranty that the request
that comes first will be served or passed into the JSF lifecycle first. The order
how the server-side data will be modified in case of simultaneous request might be
unpredictable. Usage of eventsQueue attribute allows to avoid possible mess. Define
the queue name explicitly, if you expect intensive Ajax traffic in your application.

The next request posted in the same queue will wait until the previos one is not
processed and Ajax Response is returned back if the "eventsQueue" attribute is defined. In addition, RichFaces starts to remove from the
queue "similar" requests. "Similar'"requests are the requests
produced by the same event. For example, according to the following code, only the
newest request will be sent to the server if you type very fast and has typed the
several characters already before the previous Ajax Response is back.

"requestDelay" attribute defines the time (in ms) that the request will be wait in the
queue before it is ready to send. When the delay time is over, the request will be
sent to the server or removed if the newest "similar" request is in a
queue already .

"ignoreDupResponses" attribute orders to ignore the Ajax Response produced by the request if
the newest "similar" request is in a queue already.
ignoreDupResponses"="true" does not cancel the
request while it is processed on the server, but just allows to avoid unnecessary
updates on the client side if the response loses the actuality.

Defining the "eventsQueue" along with "requestDelay" allows to protect against unnecessary traffic flood and synchronizes
Ajax requests order. If you have several sources of Ajax requests, you can define
the same queue name there. This might be very helpful if you have Ajax components
that invoke request asynchronously from the ones produced by events from users. For
example, <a4j:poll> or <a4j:push> . In case the requests from such components modify the same data, the
synchronization might be very helpful.

There are some reasons why the queue has been improved. In previous versions the queue had quite simple implementation: it sent to the server only the last Ajax request out of all requests coming in the queue during request delay.

The improved queue allows to

Eliminate the possibility of collisions when several JSF requests pass the JSF lifecycle at the same time. The queue prevents sending such requests. Only one request is processed. The rest ones are waiting.

Reduce the traffic between browser and the server. The "similar" requests came within request delay are absorbed. Only the last one is actually sent. Reducing the number of request reduces the server load.

There are 4 types of the queue:

Global default queue, defined in the web.xml file

View scoped default queue

View scoped named queue

Form-based default queue

In this section we will take a closer look at the listed above types of the queue
and see in more detail how they differ. Usage details are covered in the <a4j:queue> chapter.

5.6.3.1. Global default queue, defined in the web.xml file

Design details

Only one global queue will ever exist on a view

If you define more than one with this name while attempting to set its attributes a warning will appear in server console
during rendering. All the same named queues after the first instance are ignored.

The queue class name is "org.richfaces.queue.global"

Global default queue has application scope and is defined in the
web.xml

The global default queue is disabled by default, because artificial
serializing of all Ajax requests on a page can significantly affect expected
behavior. The global default queue causes all Asynchronous JavaScript And XML requests becoming synchronous via the single global queue.
If the global queue is turned on it can change the behavior on all views of the application without any visible or obvious setting.

5.6.3.2. View scoped default queue

Design details

Only one default queue is ever active at one time for a given view or form.

If ever more are detected a warning will appears in server console during rendering.
All the same named queues after the first instance are ignored.

View scoped default queue is also created
for components which have the following Ajax attributes: (in this case queue has a component scope)

"requestDelay"

"ignoreDupResponce"

View scoped default queue is created automatically if the "eventsQueue" attribute is defined with some name in a component but not found in the view. It has a scope the same as defined in corresponding context param.

The view scoped default, named and formed-based types of queue utilize the
<a4j:queue> tag to override the
settings of the global queue defined in the web.xml file.

You can also programmatically enable/disable the global queue on a single
view using the following:

View scoped queue can be also added by just definition of the queue
without name specified. In this case it should be placed anywhere outside
the forms in order not to be recognized as a form-based queue.

...<a4j:queue ... />...

5.6.3.3. View scoped named queue

Design details

Named queues must have a unique name,
if a second queue with the same name is defined all the same named queues after the first instance are ignored.

Form elements are used as naming container for the queue i.e. custom queue defined within the form cannot be used by the components outside this concrete form.

You can reference a named queue from any Ajax4JSF or RichFaces
component that supports the "eventsQueue" attribute. Below
there is an example of how the components can reference a named
queue.

In this example, two components(<a4j:queue>,
<rich:comboBox>,) reference the named ( "sampleQueue") queue via the
"eventsQueue" attribute.

5.6.3.4. Form based default queue

Design details

Only one enabled form based default queue can be active at a time.

A warning appears in server console during rendering if more than one enabled form based queue exists.
All queues with the same name after the first instance should be ignored.

Users can define more than one form queue, however all but one must be disabled.

Queues are often used within forms, but defining the "eventsQueue" attribute on every component within a form can be tedious work.
To avoid that you can create a default queue for a form (overriding the global default queue ).

5.6.3.5. Queue functionality

5.6.3.5.1. Events Similarity

By default all the events raised by the same component
are similar to the queue (according to client Id of event source).
This means that if new requests come from the same component they are combined with the previous ones.
For example: if we use a4j:support on an input field and the user types frequently
all the request raised by key up during requestDelay will be combined into one.

You can also manually specify multiple components which will produce similar requests. The "similarityGroupingId" attribute is added to all the Ajax action components with 3.3.0 release.
Hence, for example, you can add two <a4j:support/> components to the input
(one for key up and the second for blur) and define that request events are similar by specifying the same "similarityGroupingId".

5.6.3.5.2. Similar requests during request delay

As written above requests are collected in the queue during requestDelay and similar ones are combined.
But similar requests can only be combined if they are raised sequentially.
This is done in order not to block the queue and not to change the requests order.

Example:

A request with some delay comes to the queue, let it be A1 the delay counter for this request is started.
If similar request(e.g. from the same component - A2) appears - these two requests are combined(A1A2 to Acombined ) and the counter is reset.

But if some not similar request comes to the queue B1 - it is placed after the first one(Acombined,B1). And if the Acombined request doesn't exit the queue and another request similar to A (let is be A3) appears again - these requests are not combined with the first one.
The request is placed after B1. (Acombined, B1, A3).

Such behavior allows

to maximize similar requests throughput

to send only the latest fields state for similar requests

not to block the queue if the different types of requests comes to queue and should wait one for another

The <a4j:poll> component has delay time 0 by default staring from 3.3.0 version in order not to use the queue delay(its own value for this parameter redefines queue's parameter) to avoid blocking periodical update in the queue. You can redefine this on the component level if need.

5.6.3.5.3. JavaScript API

Table 5.1. JavaScript API

Function

Description

getSize()

Returns the current size to the queue

getMaximumSize()

Returns the maximum size to the queue, specified in the "size" attribute

5.6.4. Data Processing Options

RichFaces uses form based approach for Ajax request sending. This means each
time, when you click an Ajax button or <a4j:poll> produces an asynchronous request, the data from the closest JSF form is
submitted with the XMLHTTPRequest object. The form data contains the values from the
form input element and auxiliary information such as state saving data.

When "ajaxSingle" attribute value is "true" , it orders to include only a value
of the current component (along with <f:param> or <a4j:actionparam> values if any) to the request map. In case of <a4j:support> , it is a value of the parent component. An example is placed below:

In this example the request contains only the input component causes the request
generation, not all the components contained on a form, because of
ajaxSingle="true" usage.

Note, that ajaxSingle="true" reduces the upcoming traffic,
but does not prevent decoding other input components on the server side. Some JSF
components, such as <h:selectOneMenu> do recognize the missing data in the request map value as a null value
and try to pass the validation process with a failed result. Thus, use <a4j:region> to limit a part of the component tree that will be processed on the
server side when it is required.

"immediate" attribute has the same purpose as any other non-JSF component. The
default "ActionListener" should be executed immediately (i.e. during the Apply Request Values
phase of a request processing lifecycle), rather than waiting until the Invoke
Application phase. Using immediate="true" is one of the ways
to have some data model values updated when other cannot be updated because of a
problem with passing the Validation phase successfully. This might be important
inside the <h:dataTable> like components where using <a4j:region> is impossible due to the <h:dataTable> component architecture.

"bypassUpdates" attribute allows to bypass the Update Model phase. It might be useful if
you need to check your input against the available validator, but not to update the
model with those data. Note, that an action will be invoked at the end of the
Validation phase only if the Validation phase is passed successfully. The listeners
of the Application phase will not be invoked in any case.

5.6.5. Action and Navigation

Ajax component is similar to any other non-Ajax JSF component like <h:commandButton> . It allows to submit the form. You can use "action" and "actionListener" attributes to invoke the action method and define the action event.

"action" method must return null if you want to have an Ajax Response with a
partual page update. This is regular mode called "Ajax request generates
Non-Ajax Response". In case of action does not return null, but the
action outcome that matches one of navigation rules, RichFaces starts to work in
"Ajax request generates Non-Ajax Response" mode. This
mode might be helpful in two major cases:

RichFaces allows to organize a page flow inside the <a4j:include> component. This is a typical scenario for Wizard like behavior.
The new content is rendered inside the <a4j:include> area. The content is taken from the navigation rule of the faces
configuration file (usually, the faces-config.xml). Note, that the content
of the "wizard" is not isolated from the rest of the page. The included page
should not have own <f:view> (it does not matter if you use facelets). You need to have an
Ajax component inside the <a4j:include> to navigate between the wizard pages. Otherwize, the whole page
update will be performed.

If you want to involve the server-side validators and navigate to the
next page only if the Validation phase is passed successfully, you can
replace <h:commandButton> with <a4j:commandButton>
and point to the action method that navigates to the next page.
If Validation process fails, the partial page update will occur and you will
see an error message. Otherwize, the application proceeds to the next page.
Make sure, you define <redirect/> option for the navigation rule to avoid memory leaks.

5.6.6. JavaScript Interactions

RichFaces allows writing Ajax-enabled JSF application without writing any
Javascript code. However, you can still invoke the JavaScript code if you need.
There are several Ajax attributes that helps to do it.

"onsubmit" attribute allows to invoke JavaScript code before an Ajax request is
sent. If "onsubmit" returns "false" , the Ajax request is canceled. The code of
"onsubmit" is inserted before the RichFaces Ajax call. Hence, the "onsubmit" should not has a "return" statement if you want the Ajax
request to be sent. If you are going to invoke a JavaScript function that returns
"true" or "false" , use the conditional statement to return
something only when you need to cancel the request. For example:

...onsubmit="if (mynosendfunct()==false){return false}"...

"onclick" attribute is similar to the "onsubmit" , but for clickable components such as <a4j:commandLink> and <a4j:commandButton> . If it returns "false" , the Ajax request is canceled also.

The "oncomplete" attribute is used for passing JavaScript that would be invoked right
after the Ajax response returns back and DOM is updated. It is not recommended to
use use keyword this inside the EL-expression, because it will not
always point to the component where Ajax request was initiated.

"onbeforedomupdate" attribute defines JavaScript code for call after Ajax response receiving
and before updating DOM on a client side.

"data" attribute allows to get the additional data from the server during an
Ajax call. You can use JSF EL to point the property of the managed bean and its
value will be serialized in JSON format and be available on the client side. You can
refer to it using the "data" variable. For example:

5.6.8. Other useful attributes

"status" attribute for Ajax components (such as <a4j:commandButton> , <a4j:poll> , etc.) points to an ID of <a4j:status> component. Use this attribute if you want to share <a4j:status> component between different Ajax components from different regions. The
following example shows it.

In the example <a4j:support> and <a4j:commandButton> are defined in different regions. Values of "status" attribute for these components points to an ID of <a4j:support> .Thus, the <a4j:support> component is shared between two components from different regions.

Other useful attribute is "focus" . It points to an ID of a component where focus will be set after an
Ajax request.

5.6.9. Common Ajax Attributes

This section of the guide summarizes all Ajax-related attributes that both rich and a4j components have.

Table 5.2. Title of the table

Attribute

Description

A4J Components

Rich Components

ajaxSingle

Limits JSF tree processing (decoding, conversion, validation and model updating) only to a component that sends the request. Boolean. Default value is "false".

<a4j:form>

<a4j:support>

<a4j:commandButton>

<a4j:commandLink>

<a4j:jsFunction>

<a4j:poll>

<a4j:push>

<rich:dataFilterSlider>

<rich:dataFilterSlider>

<rich:datascroller>

<rich:dropSupport>

<rich:menuItem>

<rich:tree>

<rich:treeNode>

<rich:panelMenuGroup>

<rich:panelMenuItem>

<rich:progressBar>

<rich:simpleTogglePanel>

<rich:tab>

<rich:toggleControl>

<rich:toolTip>

<rich:calendar>

<rich:fileUpload>

<rich:suggestionbox>

bypassUpdates

If "true", after process validations phase it skips updates of model beans on a force render response. It can be used for validating components input

<a4j:form>

<a4j:support>

<a4j:commandButton>

<a4j:commandLink>

<a4j:jsFunction>

<a4j:poll>

<a4j:push>

<rich:dataFilterSlider>

<rich:datascroller>

<rich:scrollableDataTable>

<rich:dropSupport>

<rich:menuItem>

<rich:tree>

<rich:treeNode>

<rich:panelMenuGroup>

<rich:panelMenuItem>

<rich:progressBar>

<rich:simpleTogglePanel>

<rich:calendar>

<rich:suggestionbox>

limitToList

If "true", then of all AJAX-rendered on the page components only those will be updated,
which ID's are passed to the "reRender" attribute of the describable component.
"false"-the default value-means that all components with ajaxRendered="true" will be updated.

<a4j:form>

<a4j:support>

<a4j:commandButton>

<a4j:jsFunction>

<a4j:poll>

<a4j:push>

<rich:ajaxValidator>

<rich:dataFilterSlider>

<rich:datascroller>

<rich:dragSupport>

<rich:dropSupport>

<rich:menuItem>

<rich:tree>

<rich:treeNode>

<rich:panelMenuGroup>

<rich:panelMenuItem>

<rich:progressBar>

<rich:simpleTogglePanel>

<rich:tab>

<rich:toggleControl>

<rich:calendar>

<rich:suggestionbox>

reRender

Id['s] (in format of call UIComponent.findComponent()) of components, rendered in case of AjaxRequest caused by this component. Can be single id, comma-separated list of Id's, or EL Expression with array or Collection

<a4j:form>

<a4j:support>

<a4j:commandButton>

<a4j:commandLink>

<a4j:jsFunction>

<a4j:poll>

<a4j:push>

<rich:ajaxValidator>

<rich:dataFilterSlider>

<rich:datascroller>

<rich:dataTable>

<rich:extendedDataTable>

<rich:scrollableDataTable>

<rich:dragSupport>

<rich:dropSupport>

<rich:menuItem>

<rich:tree>

<rich:treeNode>

<rich:panelMenuGroup>

<rich:panelMenuItem>

<rich:progressBar>

<rich:simpleTogglePanel>

<rich:tab>

<rich:calendar>

<rich:suggestionbox>

process

Id['s] (in format of call UIComponent.findComponent()) of components, processed at the phases 2-5 in case of AjaxRequest caused by this component. Can be single id, comma-separated list of Id's, or EL Expression with array or Collection

Name of requests queue to avoid send next request before complete other from same event. Can be used to reduce number of requests of frequently events (key press, mouse move etc.)

<a4j:form>

<a4j:support>

<a4j:commandButton>

<a4j:commandLink>

<a4j:jsFunction>

<a4j:poll>

<a4j:push>

<rich:ajaxValidator>

<rich:dataFilterSlider>

<rich:datascroller>

<rich:scrollableDataTable>

<rich:dragSupport>

<rich:dropSupport>

<rich:menuItem>

<rich:tree>

<rich:panelMenuGroup>

<rich:panelMenuItem>

<rich:progressBar>

<rich:simpleTogglePanel>

<rich:tab>

<rich:toggleControl>

<rich:calendar>

<rich:suggestionbox>

requestDelay

Attribute defines the time (in ms.) that the request will be wait in the queue before it is ready to send.
When the delay time is over, the request will be sent to the server or removed if the newest 'similar' request is in a queue already

Attribute allows to ignore an Ajax Response produced by a request if the newest 'similar' request is
in a queue already. ignoreDupResponses="true" does not cancel the request while it is processed on the server,
but just allows to avoid unnecessary updates on the client side if the response isn't actual now

<a4j:form>

<a4j:support>

<a4j:commandButton>

<a4j:jsFunction>

<a4j:poll>

<a4j:push>

<a4j:queue>

<rich:ajaxValidator>

<rich:dataFilterSlider>

<rich:datascroller>

<rich:scrollableDataTable>

<rich:dragSupport>

<rich:dropSupport>

<rich:menuItem>

<rich:tree>

<rich:treeNode>

<rich:panelMenuGroup>

<rich:panelMenuItem>

<rich:progressBar>

<rich:simpleTogglePanel>

<rich:tab>

<rich:toggleControl>

<rich:calendar>

<rich:suggestionbox>

timeout

Response waiting time on a particular request. If a response is not received during this time, the request is aborted

<a4j:form>

<a4j:form>

<a4j:support>

<a4j:commandButton>

<a4j:commandLink>

<a4j:jsFunction>

<a4j:poll>

<a4j:push>

<a4j:queue>

<rich:ajaxValidator>

<rich:dataFilterSlider>

<rich:datascroller>

<rich:scrollableDataTable>

<rich:dragSupport>

<rich:dropSupport>

<rich:menuItem>

<rich:tree>

<rich:treeNode>

<rich:panelMenuGroup>

<rich:panelMenuItem>

<rich:progressBar>

<rich:simpleTogglePanel>

<rich:tab>

<rich:toggleControl>

<rich:suggestionbox>

similarityGroupingId

If there are any component requests with identical IDs then these requests will be grouped.

<a4j:form>

<a4j:support>

<a4j:commandButton>

<a4j:commandLink>

<a4j:jsFunction>

<a4j:poll>

<rich:ajaxValidator>

<rich:dataFilterSlider>

<rich:datascroller>

<rich:scrollableDataTable>

<rich:dragSupport>

<rich:dropSupport>

<rich:menuItem>

<rich:tree>

<rich:treeNode>

<rich:panelMenuGroup>

<rich:panelMenuItem>

<rich:progressBar>

<rich:simpleTogglePanel>

<rich:tab>

<rich:toggleControl>

<rich:calendar>

<rich:suggestionbox>

<rich:message>

<rich:messages>

keepTransient

Flag for mark all child components to non-transient. If "true", all children components will be set to non-transient state and keep in saved components tree.
For output in self-renderer region all content (By default, all content in <f:verbatim> tags and non-jsf elements in facelets, marked as transient - since, self-rendered ajax regions don't plain output for ajax processing).
The default value is "false".

<a4j:include>

<a4j:outputPanel>

ajaxListener

MethodExpression representing an action listener method that will be notified when this component is activated by the ajax Request and handle it. The expression must evaluate to a public method that takes an AjaxEvent parameter, with a return type of void.

<a4j:include>

<a4j:outputPanel>

selfRendered

if "true", self-render subtree at InvokeApplication ( or Decode, if immediate property set to true ) phase

<a4j:page>

<a4j:region>

<rich:suggestionbox>

immediate

Flag indicating that, if this component is activated by ajaxrequest, notifications should be delivered to interested listeners and actions immediately (that is, during Apply Request Values phase) rather than waiting until Invoke Application phase

5.7. How To...

5.7.1. Send an Ajax request

There are different ways to send Ajax requests from your JSF page. For example
you can use <a4j:commandButton> , <a4j:commandLink> , <a4j:poll> or <a4j:support> tags or any other.

All these tags hide the usual JavaScript activities that are required for an
XMHTTPRequest object building and an Ajax request sending. Also, they allow you to
decide which components of your JSF page are to be re-rendered as a result of the
Ajax response (you can list the IDs of these components in the "reRender" attribute).

<a4j:commandButton> and <a4j:commandLink> tags are used to send an Ajax request on "onclick" JavaScript event.

<a4j:poll> tag is used to send an Ajax request periodically using a timer.

5.7.2. Decide What to Send

You may describe a region on the page you wish to send to the server, in this way
you can control what part of the JSF View is decoded on the server side when you
send an Ajax request.

The easiest way to describe an Ajax region on your JSF page is to do nothing,
because the content between the <f:view> and </f:view> tags is considered the default Ajax region.

You may define multiple Ajax regions on the JSF page (they can even be nested) by
using the <a4j:region> tag.

If you wish to render the content of an Ajax response outside of the active
region then the value of the "renderRegionOnly" attribute should be set to "false" ("false" is
default value). Otherwise, your Ajax updates are limited to elements of the active
region.

5.7.3. Decide What to Change

Using IDs in the "reRender" attribute to define "AJAX zones" for update works
fine in many cases.

But you can not use this approach if your page contains, e.g. a <f:verbatim> tag and you wish to update its content on an Ajax response.

The problem with the <f:verbatim/> tag as described above is related to the value of the transientFlag of
JSF components. If the value of this flag is true, the component must not
participate in state saving or restoring of process.

In order to provide a solution to this kind of problems, RichFaces uses the
concept of an output panel that is defined by the <a4j:outputPanel> tag. If you put a <f:verbatim> tag inside of the output panel, then the content of the <f:verbatim/> tag and content of other panel's child tags could be updated on
Ajax response. There are two ways to control this:

By setting the "ajaxRendered" attribute value to "true".

By setting the "reRender" attribute value of an Action Component to the output panel
ID.

5.7.4. Decide what to process

The "process" attribute allows to define the ids of components to be processed
together with the component which is marked as ajaxSingle or
wrapped to region.

You could make use of the "process" attribute when you need to process only two components in the different
parts of view.

Imagine you need to process only two input fields but not all the view. If you
wrap the first input to region or make <a4j:support> component with ajaxSingle="true" nested the
second input will not be processed.

In the example above when the input field with the
id="name" looses focus, an Ajax request is sent. So only
two input fields (with id="name" and additionally with
id="email") are processed: decoding,
conversion/validation, value applying phases are executed. The input field with the
id="email" is handled the same way on blur event.

5.8. Filter Configuration

RichFaces uses a filter for a correction of code received on an Ajax request. In case
of a "regular" JSF request a browser makes correction independently. In case
of Ajax request in order to prevent layout destruction it's needed to use a filter,
because a received code could differ from a code validated by a browser and a browser
doesn't make any corrections.

An example of how to set a Filter in a web.xml file of your application is placed
below.

Note:

Fast Filter is deprecated and available only for backward compatibility with
previous RichFaces versions. Fast Filter usage isn't recomended, because there
is another way to use its functionality by means of Neko filter
type .

From RichFaces 3.2 filter configuration becomes more flexible. It's possible to
configure different filters for different sets of pages for the same application.

The possible filter types are:

TIDY

"TIDY" filter type based on the Tidy parser. This filter is recommended for
applications with complicated or non-standard markup when all necessary code corrections
are made by the filter when a response comes from the server.

NEKO

"NEKO" filter type corresponds to the former "Fast Filter" and
it's based on the Neko parser. In case of using this filter code isn't
strictly verified. Use this one if you are sure that your application markup is really
strict for this filter. Otherwise it could cause lot's of errors and corrupt a
layout as a result. This filter considerably accelerates all Ajax requests processing.

The example shows that ORDER parameter defines the order in which
particular filter types are used for pages code correction.

First of all "NONE" type is specified for the filter. Then two different
sets of pages are defined for which two filter types (NONE and NEKO) are used
correspondingly. If a page relates to the first set that is defined in the following
way:

it's not corrected, because filter type for this page is defined as
"NONE". If a page is not from the first set, then "NEKO" type is
set.

If a page relates to the second set that is defined in the following way:

<param-value>/pages/repeat\.xhtml</param-value>

then "NEKO" filter type is used for correction. If it's not related to
the second set, "TIDY" type is set for the filter ("TIDY" filter
type is used for code correction).

5.9. Scripts and Styles Load Strategy

Before the version 3.1.3, RichFaces loaded styles and script on demand. I.e. files
are loaded only if they are required on a particular page. Since RichFaces 3.1.3,
it's possible to manage how the RichFaces script and style files are loaded to
application.

org.richfaces.LoadScriptStrategy

The following declaration in your web.xml allows loading the integrated script files.

The integrated style sheet contains style for all shipped components. The
skinnability feature still works.

The "DEFAULT" value is a classical on-demand variant.

The "NONE" stops loading the styles at all. The earlier introduced plain
skin resets all color and font parameters to null. The "NONE" value for
org.richfaces.LoadStyleStrategy means that predefined styles for
RichFaces are not used.

5.11.1. Why Skinnability

If you have a look at a CSS file in an enterprise application, for example, the
one you're working on now, you'll see how often the same color is noted in
it. Standard CSS has no way to define a particular color abstractly for defining as
a panel header color, a background color of an active pop-up menu item, a separator
color, etc. To define common interface styles, you have to copy the same values over
and over again and the more interface elements you have the more copy-and-paste
activity that needs to be performed.

Hence, if you want to change the application palette, you have to change all
interrelating values, otherwise your interface can appear a bit clumsy. The chances
of such an interface coming about is very high, as CSS editing usually becomes the
duty of a general developer who doesn't necessarily have much knowledge of user
interface design.

Moreover, if a customer wishes to have an interface look-and-feel that can be
adjusted on-the-fly by an end user, your work is multiplied, as you have to deal
with several CSS files variants, each of which contains the same values repeated
numerous times.

These problems can be solved with the skinnability system
built into the RichFaces project and implemented fully in RichFaces. Every named skin
has some skin-parameters for the definition of a palette and the other parameters of
the user interface. By changing just a few parameters, you can alter the appearance
of dozens of components in an application in a synchronized fashion without messing
up user interface consistency.

The skinnability feature can't completely replace
standard CSS and certainly doesn't eliminate its usage. Skinnability is a high-level extension of standard CSS, which can be
used together with regular CSS declarations. You can also refer to skin parameters
in CSS via JSF Expression Language. You have the complete ability to synchronize the
appearance of all the elements in your pages.

5.11.2. Using Skinnability

RichFaces skinnability is designed for mixed usage with:

Skin parameters defined in the RichFaces framework

Predefined CSS classes for components

User style classes

The color scheme of the component can be applied to its elements using any of
three style classes:

A default style class inserted into the framework

This contains style parameters linked to some constants from a skin. It
is defined for every component and specifies a default representation level.
Thus, an application interface could be modified by changing the values of
skin parameters.

A style class of skin extension

This class name is defined for every component element and inserted into
the framework to allow defining a class with the same name into its CSS
files. Hence, the appearance of all components that use this class is
extended.

User style class

It's possible to use one of the styleClass parameters for component
elements and define your own class in it. As a result, the appearance of one
particular component is changed according to a CSS style parameter specified
in the class.

5.11.3. Example

Here is a simple panel component:

Example:

<rich:panel> ... </rich:panel>

The code generates a panel component on a page, which consists of two elements: a
wrapper <div> element and a <div> element for the panel body with the particular style properties. The
wrapper <div> element looks like:

Example:

<divclass="dr-pnl rich-panel"> ...</div>

dr-pnl is a CSS class specified in the framework via skin parameters:

background-color is defined with generalBackgroundColor

border-color is defined with panelBorderColor

It's possible to change all colors for all panels on all pages by changing
these skin parameters.

However, if a <rich:panel> class is specified somewhere on the page, its parameters are also
acquired by all panels on this page.

A developer may also change the style properties for a particular panel. The
following definition:

Example:

<rich:panelstyleClass="customClass"/>

Could add some style properties from customClass to one particular panel, as a
result we get three styles:

5.11.4. Skin Parameters Tables in RichFaces

To plug one in, it's necessary to specify a skin name in the
org.richfaces.SKIN context-param.

Here is an example of a table with values for one of the main skins, "blueSky" .

Table 5.3. Colors

Parameter name

Default value

headerBackgroundColor

#BED6F8

headerGradientColor

#F2F7FF

headTextColor

#000000

headerWeightFont

bold

generalBackgroundColor

#FFFFFF

generalTextColor

#000000

generalSizeFont

11px

generalFamilyFont

Arial, Verdana, sans-serif

controlTextColor

#000000

controlBackgroundColor

#ffffff

additionalBackgroundColor

#ECF4FE

shadowBackgroundColor

#000000

shadowOpacity

1

panelBorderColor

#BED6F8

subBorderColor

#ffffff

tabBackgroundColor

#C6DEFF

tabDisabledTextColor

#8DB7F3

trimColor

#D6E6FB

tipBackgroundColor

#FAE6B0

tipBorderColor

#E5973E

selectControlColor

#E79A00

generalLinkColor

#0078D0

hoverLinkColor

#0090FF

visitedLinkColor

#0090FF

Table 5.4. Fonts

Parameter name

Default value

headerSizeFont

11px

headerFamilyFont

Arial, Verdana, sans-serif

tabSizeFont

11px

tabFamilyFont

Arial, Verdana, sans-serif

buttonSizeFont

11px

buttonFamilyFont

Arial, Verdana, sans-serif

tableBackgroundColor

#FFFFFF

tableFooterBackgroundColor

#cccccc

tableSubfooterBackgroundColor

#f1f1f1

tableBorderColor

#C0C0C0

Skin "plain" was added from 3.0.2 version. It doesn't have any parameters.
It's necessary for embedding RichFaces components into existing projecst which
have its own styles.

To get detailed information on particular parameter possibilities, see the chapter where each component has
skin parameters described corresponding to its elements.

5.11.5. Creating and Using Your Own Skin File

In order to create your own skin file, do the following:

Create a file and define in it skin constants which are used by style
classes (see section
"Skin Parameters Tables in RichFaces"
). The name of skin file should correspond to the following format:
<name>.skin.properties . As an example of such file
you can see RichFaces predefined skin parameters (skins): blueSky, classic,
deepMarine, etc. These files are located in the
richfaces-impl-xxxxx.jar inside the /META-INF/skins folder.

Add a skin definition <contex-param> to the web.xml of
your application. An example is placed below:

Put your <name>.skin.properties file in one of the
following classpath elements: META-INF/skins/ or classpath folder (e.g.
WEB-INF/classes).

5.11.6. Built-in Skinnability in RichFaces

RichFaces gives an opportunity to incorporate skinnability
into UI design. With this framework you can easily use named skin parameters in
properties files to control the appearance of the skins that are applied
consistently to a whole set of components. You can look at examples of predefined
skins at:

You may simply control the look-and-feel of your application by using the
skinnability service of the RichFaces framework. With the
means of this service you can define the same style for rendering standard JSF
components and custom JSF components built with the help of RichFaces.

To find out more on skinnability possibilities, follow these
steps:

Create a custom render kit and register it in the faces-config.xml like
this:

5.11.8. Standard Controls Skinning

The feature is designed to unify the look and feel of standard HTML element and
RichFaces components. Skinning can be applied to all controls on a page basing on
elements' name and attribute type (where applicable). Also this feature
provides a set of CSS styles so that skinning can be applied assigning rich-*
classes to particular elements or to container of elements that nests controls.

Standard controls skinning feature provides 2 levels of skinning: Standard and Extended. The level is based
on detecting the browser type. If browser type is not identified, Advanced level is
used. However, if you want to explicitly specify the level of skinning you want to be applied, you need to add a context parameter to your web.xml
with org.richfaces.CONTROL_SKINNING_LEVEL as the parameter name
and value set to either basic or extended.

Extended level extends basic level
introducing broader number of style properties and is applied to browsers
with rich visual styling capability of controls

The following browsers support Extended level of
skinning:

Mozilla Firefox

Internet Explorer 7 in Standards-compliant mode (CSS1Compat mode)

These are the elements that affected by skinning:

input

select

textarea

keygen

isindex

legend

fieldset

hr

a (together with a:hover, a:visited "pseudo"-elements)

Skinning for standard HTML controls can be initialized in two ways:

by adding org.richfaces.CONTROL_SKINNING parameter to web.xml.
Values: "enable" and "disable". This way implies that
skinning style properties are applied to elements by element name and
attribute type (where applicable). No additional steps required. Please find
below the table that contains the list of elements to which skinning is
applicable.

by adding org.richfaces.CONTROL_SKINNING_CLASSES parameter to
web.xml file. Possible values "enable" and "disable".
When this option is enabled you are provided with a set of predefined CSS classes
that you can use for skinning your HTML components.

By setting org.richfaces.CONTROL_SKINNING_CLASSES to
"enable" you are provided with style classes applicable to:

Attention.
The <a4j:portlet> component is DEPRECATED as far as JSR-301 was defined the same functionality for a UIViewRoot component.
Thus, it is implicitly defined by mandatory <f:view> component.

5.11.9. Client-side Script for Extended Skinning Support

As it was mentioned earlier in the guide, extended skinning of standard HTML
controls is applied automatically: the browser type is detected and if a browser
doesn't fully support extended skinning feature, only basic skinning is
applied.

However, if you don't want the RichFaces components and standard HTML
controls to be skinned automatically and perform the skinnability implementation
yourself, you might encounter with a problem, namely standard HTML controls in such
browsers as Opera and Safari will be affected by standard controls skinning. (
In this section you can get more
details on how to disable skinnability.)

In brief, to disable the skinnability mechanism of RichFaces you need to set the
"org.richfaces.LoadStyleStrategy" parameter to "NONE" in the
web.xml file.

Additionally, you should include the style sheets that perform skinning of the
RichFaces component and standard HTML controls.

In order to resolve the problem with extended skinning in Opera and Safari a
client script (skinning.js) is added to the RichFaces library. The script detects
the browser type and enables extended skinning only for those browsers that fully
support it.

The script can be activated by inserting this JavaScript code to the page:

Note

Now it's necessary to use a4j/versionXXX resources prefix instead of
a4j_versionXXX. Base64 encoder changed to use
'!' instead of '.'.

5.11.10. XCSS File Format

XCSS files are the core of RichFaces components skinnability.

XCSS is an XML formatted CSS that adds extra functionality to the skinning
process.
XCSS extends skinning possibilities by parsing the XCSS file that contains all
look-and-feel parameters of a particular component into a standard CSS file that a
web browser can recognize.

XCSS file contains CSS properties and skin parameters mappings. Mapping of a CSS
selector to a skin parameter is performed using < u:selector > and < u:style> XML tags that form the mapping structure. Please study the example
below.

During processing the code in the shown example is parsed into a standard
CSS format.

....rich-component-name{background-color:additionalBackgroundColor;/*the value of the constant defined by your skin*/border-color:tableBorderColor;/*the value of the constant defined by your skin*/border-width:tableBorderWidth;/*the value of the constant defined by your skin*/border-style:solid;}...

The "name" attribute of <u:selector> tag defines the CSS selector, while "name" attribute of the <u:style> tag defines what skin constant is mapped to a CSS property. The
"value" attribute of the <u:style> tag can also be used to assign a value to a CSS property.

CSS selectors with identical skinning properties can be set as a comma separated
list.

5.11.11. Plug-n-Skin

Plug-n-Skin is a feature that gives you an opportunity to easily create,
customize and plug into your project a custom skin. The skin can be created basing on
parameters of some predefined RichFaces skin.

The feature also provides an option to unify the appearance of rich controls with
standard HTML elements.

In order to create your own skin using Plug-n-Skin feature, you can follow these
step by step instructions.

First of all, you need to create a template for the new skin. Creation of the
template can be performed using Maven build and deployment tool. More information on
how to configure Maven for RichFaces you can find out from JBoss wiki article
. You can copy and paste these Maven instructions to command line and execute them.

BaseImageTest.java - a test version of a class that
stores images. Location:
"\src\test\java\SKIN-PACKAGE\SKIN-NAME\images\"

XCSS files - XCSS files define the new look of
RichFaces components affected by the new skin. Location:
"\src\main\resources\SKIN-PACKAGE\SKIN-NAME\css\"

SKIN-NAME.properties - a file that contains
properties of the new skin. Location:
"\src\main\resources\SKIN-PACKAGE\SKIN-NAME\css\"

The following properties are used to configure the SKIN-NAME.properties
file:

baseSkin – the name of the base skin to be used
as basis. The look of the skin you define will be affected by new
style properties.

generalStyleSheet - a path to the style sheet
(SKIN-NAME.xcss) that imports style sheets of the components to be
affected by the new skin.

extendedStyleSheet - a path to a style sheet
that is used to unify the appearance of RichFaces components and
standard HTML controls. For additional information please read "Standard controls
skinning"
chapter.

gradientType - a predefined property to set
the type of gradient applied to the new skin. Possible values are
glass, plastic, plain. More information on gradient implementation
you can find further in this chapter.

SKIN-NAME.xcss - a XCSS file that imports XCSS files of
the components to be affected by the new skin. Location:
"src\main\resources\META-INF\skins "

XCSS files If the command is executed with the
"DcreateExt" key set to "true", the XCSS
(extended_classes.xcss and extended.xcss) files that define style for
standard controls will be created. Location:
"\src\main\resources\SKIN-PACKAGE\SKIN-NAME\css\".

SKIN-NAME-ext.xcss If the command is executed with
the "DcreateExt" key set to "true", the configuration
SKIN-NAME-ext.xcss file that imports XCSS file defining styles for the
standard controls will be created. Location:
"src\main\resources\META-INF\skins ".

Now you can start editing the XCSS files located in
"\src\main\resources\SKIN-PACKAGE\SKIN-NAME\css\". New style properties
can be assigned to the selectors (the selectors listed in the XCSS files) in two
ways, which are both valid, and it'up to you what way to choose.

Standard CSS coding approach, i.e. you can add CSS properties
to the given selectors. The only
thing, you have to keep in mind is that the selectors must be inside
<f:verbatim> <![CDATA[ ...]]>
</f:verbatim> tags.

For example

....rich-calendar-cell{background:#537df8;}...

Using XCSS coding approach, the same way as XCSS files are normally
formed in RichFaces. The XCSS tags have to be placed outside
<f:verbatim> <![CDATA[ ...]]>
</f:verbatim> tags.

Having performed described above steps and edited the XCSS files you can proceed
to building the new skin and to plugging it into the project. Building the new skin
can be done by executing the given below command in the command line in the root
folder of you skin project (the one that contains pom.xml file).

...mvn clean install...

In addition Plug-n-Skin has a number of predefined gradients that you can also use
to make your application look nicer. The given below code snippet shows how a
gradient can be used

So, as you can see, the background-image CSS property is
defined with <f:resource
f:key="org.richfaces.renderkit.html.CustomizeableGradient">
that sets the gradient. While the gradient type can be specified in the
SKIN-NAME.properties file with gradientType property. The gradientType
property can be set to one of the possible values glass, plastic, plain. The
gradient in it's turn can be can be adjusted using baseColor, gradientColor,
gradientHeight, valign attributes. Their usage is shown in the snippet above.

Now, you can use your newly-created and customized skin in your project by adding
your new skin parameters to web.xml file and placing the jar file with your skin (
the jar file is located in "target" folder of your skin project) to
"\WebContent\WEB-INF\lib\".

5.11.11.1. Details of Usage

This section will cover some practical aspects of Plug-n-Skin implementation.
It's assumed that you have read the section of the guide that tells how the
new skin using Plug-n-Skin prototype can be created.

Above all, we need to create a new skin, in order to do that we just have to
follow the steps described in the previous section.

This command will be used to create a template of the new skin project.

As you remember from the previous section "-DbaseSkin" key defines
what RichFaces built-in skin to be used as a base one,
"-DcreateExt=true" determines that the new skin will come with XCSS
files that unify the look of the rich components with standard HTML controls.

So, now the files and folder with all needed resources are created and
redefining/editing the new skin can be started.

Now we can start editing XCSS files of the rich components. In order to see
how the Plug-n-Skin feature works we will change some style attributes of
<rich:calendar> and some basic HTML controls to see how they are affected by
standard controls skinning.

Thus, it will be demonstrated how to:

Recolor the current day's cell background of the <rich:calendar> to see how the new skin created with the help of Plug-n-Skin
feature affects the style of the component;

Recolor a standard HTML submit button;

In oder to edit the style properties of <rich:calendar> you need to open the "calendar.xcss" file located in
"P-n-S\src\main\resources\skinpackage\plugnskindemo\css\". Once, you
have opened the file, please find ".rich-calendar-today" selector and amend it
as follows: background-color: #075ad1;. The current day's
background color can be considered recolored.

Now we will see how font style of a standard HTML submit button can be
changed. Please, open "extended.xcss" file located in
"P-n-S\src\main\resources\skinpackage\plugnskindemo\css\" and put in
font-weight: bold; inside the curly braces of these coma
separated selectors button[type="button"],
button[type="reset"], button[type="submit"],
input[type="reset"], input[type="submit"],
input[type="button"]. So, the CSS code should look like
this.

All the changes that were planned to be preformed are done and now you can
proceed to building the new PlugnSkinDemo skin and import it into the project.
As you read in the previous section, the skin should be built in the
"P-n-S" folder of the skin project by executing mvn clean
install command. This procedure results in creating a
"target" folder that contains a .jar file with a compiled new skin, it
our case the file is named "P-n-S-1.0.-SNAPSHOT.jar". The next step is
to import the new PlugnSkinDemo skin into the project.

What you need to do, in order to have the new skin imported to the project is
to

Copy the "P-n-S-1.0.-SNAPSHOT.jar" file to the
"\WebContent\WEB-INF\lib\" folder.

5.12. Definition of Custom Style Classes

In the "Reference Data" section for most of the visual components (see "The RichFaces Components" chapter)
there are the tables with rich-* classes definitions. These classes allow to redefine styles for a specific component by means of CSS.
Actually, you should create classes with the same names and define new properties in them.

Let's consider the <rich:modalPanel> component.
To change the background color for the mask, it's enough to redefine the .rich-mpnl-mask-div class.

Example:

....rich-mpnl-mask-div{background-color:#fae6b0;}...

This is a result:

Figure 5.7. Style redefinition with predefined class

If you have multiple components on the page, the redefined styles will be applied to all of them. To change styles for a
particular component on the page, create your own style classes and use them in corresponding style class attributes. An example on how to
change the font style for the header of a particular modal panel is placed below:

Example:

....myClass{font-style:italic;}...

Next specify myClass as the value of the "headerClass" attribute for <rich:modalPanel>:

<rich:modalPanel ... headerClass="myClass"/>

This is a result:

Figure 5.8. Style redefinition with own class

5.13. State Manager API

JSF has an advanced navigation mechanism that allows you to define navigation from
view to view. Navigation happens in a Web Application when a user tries to switch from
one page to another page either by clicking a button, a hyperlink, or another command
component. But there is no switch mechanism between some logical states of the same
view. For example in Login/Register dialog an existing user signs
in with his user name and password, but if a new user registers an additional field
"Confirm" is displayed, buttons labels and methods are changed when the user
clicks "To register" link:

Figure 5.9. Login Dialog

Figure 5.10. Register Dialog

RichFaces State API allows easily to define some set of states for
the pages and any properties for this states.

Actually States is a map where the entry key is a name of the
State and the value is a State map. Particular State map has entries with some names as
keys and any objects as values that are used after the state activation. Thus, in the
State map you could define any values, method bindings, or just some simple state
variables (constants) which have different values for every State.

Figure 5.11. RichFaces State API

One of the most convenience features of the RichFaces State API
is a navigation between states. The RichFaces State API implements
states change as the standard JSF navigation. Action component just returns outcome and
the RichFaces State API extension for the JSF navigation handler
checks whether this outcome is registered as a state change outcome
or not. If the state change outcome is found the corresponding
state is activated. Otherwise the standard navigation handling is called.

In order to use RichFaces State API you should follow the next
steps:

Register State Manager EL resolver and navigation handler in the faces-config.xml:

5.14. Identifying User Roles

RichFaces provides a function to check whether the logged-in user belongs to a certain user role. The function is rich:isUserInRole(Object), it takes a String, a comma-separated list String, Collection etc. as arguments and returns a boolean value.

For example, you need to render some controls only for administrators.
To do this you need to create a role "admin" in web.xml and implement authorisation that assigns the "admin" role to the user that loggged-in as an administrator. Afterwards, you can use the rich:isUserInRole(Object) function with the "rendered" attribute of any component.

6.1.1.
<
a4j:ajaxListener
>
available since
3.0.0

6.1.1.1. Description

The
<a4j:ajaxListener>
component adds an action listener to a parent component and works like the
<f:actionListener>
or
<f:valueChangeListener>
JSF components
but for the whole Ajax container.

6.1.1.2. Details of Usage

The
<a4j:ajaxListener>
component adds an action listener to a parent component.
That listener is invoked on each Ajax request during the "Render Response" JSF phase.
In comparison with standard JSF
<f:actionListener>
and
<f:valueChangeListener>
components the invocation of the
<a4j:ajaxListener>
is not skipped in case when validation of "Update Model" fails.
The
<a4j:ajaxListener>
is guarantied to be invoked for each Ajax response.

The
"type"
attribute defines the fully qualified Java class name for the listener.
This Java class should implement
org.ajax4jsf.event.AjaxListener
interface which is base interface for all listeners, capable for receiving Ajax events.
The object on which the Event initially occurred could be accessed using the
java.util.EventObject.getSource()
method.

The
<a4j:ajaxListener>
is not invoked for non-Ajax requests and when RichFaces works in the "Ajax Request
generates Non-Ajax Response" mode, so
<a4j:ajaxListener>
invocation is a good indicator that Ajax
Response is going to be processed. Let's check it in the following example.

6.1.2.
<
a4j:actionparam
>
available since
3.0.0

6.1.2.1. Description

The
<a4j:actionparam>
component combines the functionality of
<f:param>
and
<f:actionListener>
and allows to assign the value to the property of the managed bean directly using the
"assignTo"
attribute.

6.1.2.2. Details of Usage

The
<a4j:actionparam>
component has 3 main attributes:

"name"
defines a name of this parameter

"value"
defines initial value of this parameter or a value binding

"assignTo"
defines updatable bean property. This property will be updated if the parent
command component performs an actionEvent. The update occurs in the same phase as the actionEvent is processed (INVOKE_APPLICATION, PROCESS_VALIDATIONS, or APPLY_REQUEST_VALUES, depending on the values of the
"immediate"
and
"bypassUpdates"
attributes).

Example:

...<h:formid="form"><a4j:commandButtonvalue="Set Name to Alex"reRender="rep"><a4j:actionparamname="username"value="Alex"assignTo="#{actionparamBean.name}"/></a4j:commandButton><br/><h:outputTextid="rep"value="Name: #{actionparamBean.name}"/></h:form>...

You can use
<a4j:actionparam>
not only with Ajax components, but with non-ajax command component also.
This feature allows to update model values without invoking even a single line of Java code on the
server side. The usage of this feature you can find at
ActionParameter Usage
page of RichFaces LiveDemo.

If you need to convert the value before the "Update Model" phase
you can specify the converter in the
"converter"
attribute.

Note:

The property is assigned with a parameter value on the "Update Model" phase. Therefore if the
validation of the form is failed, this phase will be skipped and the property won't be updated.

It is possible to use JavaScript expression or function in the
"value"
attribute.
In this case the
"noEscape"
attribute should be set to "true".
The result of this JavaScript invocation is sent to the server as a value of
<a4j:actionparam>
.

6.1.3.
<
a4j:form
>
available since
3.0.0

6.1.3.1. Description

The
<a4j:form>
component enhances functionality of the standard JSF
<h:form>
component with possibility of default Ajax submission
and fixes the problem with
<h:commandLink>
generation inside the form.

6.1.3.2. Details of Usage

Along with
a4j:htmlCommandLink
,
<a4j:form>
component fixes the problem of
<h:commandLink>
component that cannot be re-rendered
without re-rendering the whole form it belongs to. For the further details see the
Ajax Form Usage
page at RichFaces Livedemo.

The
<a4j:form>
component adds extra functionality to non-Ajax action/command components: submission is performed
via Ajax when
"ajaxSubmit"
attribute set to "true".

If the
<a4j:form>
component
works in an Ajax mode, the standard Ajax attributes such as
"reRender"
,
"limitToList"
,
"requestDelay"
, etc. can be used.

Example:

...<a4j:formajaxSubmit="true"reRender="name"><h:panelGrid><h:commandButtonvalue="Set Local Name to John (Ajax)"action="#{userBean.nameItJohn}"/><h:outputTextid="name"value="Name:#{userBean.name}"/></h:panelGrid></a4j:form>...

In the example above the
ajaxSubmit="true",
so all standard action components on this form become ajaxable.
The
"reRender"
attribute contains an Id of component for
re-rendering after an Ajax response.

Tip:

If you have
<h:commandButton>
or
<h:commandLink>
inside a form, they work as
<a4j:commandButton>
.

Note:

You should not use
<a4j:form>
component with
ajaxSubmit="true"
if it contains other Ajax command components.
Also, due to the security reason, file upload form element cannot be convertible to the be ajaxable.

6.1.4.
<
a4j:region
>
available since 3.0.0

6.1.4.1. Description

The <a4j:region> component specifies the part of the component tree to be processed on server.
If no <a4j:region> is defined the whole View functions as a region.

6.1.4.2. Details of Usage

The <a4j:region> component specifies the part of the component tree to be processed on server.
The processing includes data handling during decoding, conversion, validation and model update.
Note that the whole Form is still submitted but only part taken into region will be processed.

Example:

<h:form> ...<a4j:region><a4j:commandLink/></a4j:region> ...<h:form>

The whole Form on the schematic listing above will be submitted by request invoked with the <a4j:commandLink>.
The only part that is going to be processed on the server is enclosed with <a4j:region> and </a4j:region> tags.
If no <a4j:region> is defined the whole View functions as a region.

The regions could be nested. Server picks out and decodes only the region, which contains the component that initiates the request.

The external region is decoded for link1 and the internal one is decoded for link2.

The "renderRegionOnly" attribute is used when it is necessary to exclude all the components from the outside of the region from updating on the page during Renderer Response phase.
Such manipulation allows region to be passed straight into Encode and reduces performance time.
This optimization should be implemented carefully because it doesn't allow data from the outside of active region to be updated.

On the example above the first region only will be updated if link1 initiates a request.
When a request is initiated by link2 both regions will be updated.
In this case search for components to include them into Renderer Response will be performed on the whole component tree.

RichFaces allows setting Ajax responses rendering basing on component tree nodes directly, without referring to the JSP (XHTML) code.
This speeds up a response output considerably and could be done by setting the <a4j:region>"selfRendered" attribute to "true".
However, this rapid processing could cause missing of transient components that present on view and don't come into a component tree as well as omitting of <a4j:outputPanel> usage described below.

In this case the processing is quicker and going on without referring to the page code.
The HTML code is not saved in a component tree and could be lost.
Thus, such optimization should be performed carefully and additional RichFaces components usage (e.g. <a4j:outputPanel>) is required.

Starting from RichFaces 3.2.0 the <a4j:region> can be used together with iterative components (e.g. <rich:column> or <rich:scrollableDataTable>, etc.).
It became possible to re-render a particular row in a table without updating the whole table and without any additional listeners.

6.1.5.
<
a4j:support
>
available since 3.0.0

6.1.5.1. Description

The <a4j:support> component
is the most important core component in the RichFaces library.
It enriches any existing non-Ajax JSF or RichFaces component with Ajax capability.
All other RichFaces Ajax components are based on the same principles
<a4j:support> has.

6.1.5.2. Details of Usage

The <a4j:support>
component has two key attributes:

mandatory
"event" attribute that defines the JavaScript event
the Ajax support will be attached to

"reRender" attribute that defines id(s)
of JSF component(s) that should be rerendered after an Ajax request

We begin with the common behavior description. When a page is rendered you see only one select box with the list of planets.
When you select a planet the <h:dataTable>
containing moons of the selected planet appears.

In other words we need <h:selectOneMenu>
with the nested <a4j:support> component that
is attached to the onchange event.

When an Ajax response comes back the <h:dataTable>
is re-rendered on the server side and updated on the client.

...<h:formid="planetsForm"><h:outputLabelvalue="Select the planet:"for="planets"/><h:selectOneMenuid="planets"value="#{planetsMoons.currentPlanet}"valueChangeListener="#{planetsMoons.planetChanged}"><f:selectItemsvalue="#{planetsMoons.planetsList}"/><a4j:supportevent="onchange"reRender="moons"/></h:selectOneMenu><h:dataTableid="moons"value="#{planetsMoons.moonsList}"var="item"><h:column><h:outputTextvalue="#{item}"/></h:column></h:dataTable></h:form>...

There are two properties planetsList and moonsList.
The planetsList is filled with planets names in the constructor.
After you select the planet,
the planetChanged() listener is called and
the moonsList is populated with proper values of moons.

With the help of
"onsubmit"
and
"oncomplete"
attributes the <a4j:support> component
allows to use JavaScript calls before and after an Ajax request
respectively.
Actually the JavaScript specified in the "oncomplete" attribute
will be executed in any case whether the Ajax request is completed successfully or not.

You can easily add confirmation dialog for the planet select box and colorize
<h:dataTable> after the Ajax response:

...<h:formid="planetsForm"><h:outputLabelvalue="Select the planet:"for="planets"/><h:selectOneMenuid="planets"value="#{planetsMoons.currentPlanet}"valueChangeListener="#{planetsMoons.planetChanged}"><f:selectItemsvalue="#{planetsMoons.planetsList}"/><a4j:supportevent="onchange"reRender="moons"onsubmit="if(!confirm('Are you sure to change the planet?')) {form.reset(); return false;}"oncomplete="document.getElementById('planetsForm:moonsPanel').style.backgroundColor='#c8dcf9';"/></h:selectOneMenu><h:dataTableid="moons"value="#{planetsMoons.moonsList}"var="item"><h:column><h:outputTextvalue="#{item}"/></h:column></h:dataTable></h:form>...

6.1.6.
<
a4j:commandButton
>
available since 3.0.0

6.1.6.1. Description

The <a4j:commandButton>component is very similar to JSF <h:commandButton>, the only difference is that an Ajax form submit is generated on a click and it allows dynamic rerendering after a response comes back.

Note:

The <a4j:commandButton> already has Ajax support built-in and there is no need to add <a4j:support>.

The usage of the keyword 'this' in JavaScript code in the value for "oncomplete" attribute depends on the location of <a4j:commandButton>.
If the <a4j:commandButton> is situated outside the re-rendered region it is possible to use keyword 'this' as in the following example:

Otherwise, if the <a4j:commandButton> is contained in a re-rendered region
than the "oncomplete" attribute has a problem with obtaining a reference of the
commandButton object when using the keyword 'this'.
In this case use the "oncomplete" attribute as in the following example:

Common JSF navigation could be performed after an Ajax submit and partial rendering, but Navigation Case must be defined as <redirect/> in order to avoid problems with some browsers.

As any Core Ajax component that sends Ajax requests and processes server responses the <a4j:commandButton> has all attributes that provide the required behavior of requests (delay, limitation of submit area and rendering, etc.)

Note:

When attaching a JavaScript API function to the <a4j:commandButton> with the help of the <rich:componentControl> do not use the "attachTo" attribute of the last one.
The attribute adds event handlers using Event.observe but <a4j:commandButton> has no such event.
The example below will not work:

<a4j:commandButtonvalue="Show Current Selection"reRender="table"action="#{dataTableScrollerBean.takeSelection}"id="button"><rich:componentControlattachTo="button"for="panel"event="oncomplete"operation="show"/></a4j:commandButton>

This one should work properly:

<a4j:commandButtonvalue="Show Current Selection"reRender="table"action="#{dataTableScrollerBean.takeSelection}"id="button"><rich:componentControlfor="panel"event="oncomplete"operation="show"/></a4j:commandButton>

6.1.7.
<
a4j:commandLink
>
available since 3.0.0

6.1.7.1. Description

The <a4j:commandLink>component is very similar to the <h:commandLink> component, the only difference is that an Ajax form submit is generated on a click and it allows dynamic rerendering after a response comes back. It's not necessary to plug any support into the component, as Ajax support is already built in.

6.1.7.2. Details of Usage

The <a4j:commandLink> component is used in the same way as JSF <h:commandLink>.
The difference is that in case of <a4j:commandLink> the components to be updated should be specified.
In this chapter we will use the code from RichFaces Greeter and change there <a4j:commandButton> to <a4j:commandLink>:

...<a4j:commandLinkvalue="Get greeting"reRender="greeting"/>...

It's not necessary to add nested <a4j:support> as the <a4j:commandLink> has an Ajax support already built-in.
As a result of our changes we will get a form with "Get greeting" link instead of the button:

If you click on the generated anchor the utility method A4J.AJAX.Submit() will be fired.

Note:

Common JSF navigation could be performed after Ajax submit and partial rendering, but Navigation Case must be defined as <redirect/> in order to avoid problems with some browsers.

As any Core Ajax component that sends Ajax requests and processes server responses the <a4j:commandLink> has all attributes that provide the required behavior of requests (delay, limitation of submit area and rendering, etc.)

6.1.8.
<
a4j:jsFunction
>
available since 3.0.0

6.1.8.1. Description

The <a4j:jsFunction> component allows to perform Ajax requests directly from JavaScript code, invoke server-side data and return it in a JSON format to use in a client JavaScript calls.

6.1.8.2. Details of Usage

As the component uses Ajax request to get data from server it has all common Ajax Action attributes.
Hence, "action" and "actionListener" can be invoked, and reRendering some parts of
the page fired after calling function.

When using the <a4j:jsFunction> it's possible to initiate the Ajax request from the JavaScript and
perform partial update of a page and/or invoke the JavaScript function with data returned by
Ajax response.

The <a4j:jsFunction> allows to use <a4j:actionparam> or pure <f:param> for passing any number of parameters of the JavaScript function into Ajax request.
<a4j:jsFunction> is similar to <a4j:commandButton>, but it could be activated from the JavaScript code.
It allows to invoke some server-side functionality and use the returned data in the JavaScript function invoked from "oncomplete" attribute.
Hence it's possible to use <a4j:jsFunction> instead of <a4j:commandButton>.
You can put it anywhere, just don't forget to use <h:form> and </h:form> around it.

6.1.9.
<
a4j:poll
>
available since 3.0.0

6.1.9.1. Description

The <a4j:poll> component allows periodical sending of Ajax requests to a server and is
used for a page updating according to a specified time interval.

6.1.9.2. Details of Usage

The <a4j:poll> componet is used for periodical polling of server data.
In order to use the component it's necessary to set an update interval.
The "interval" attribute defines an interval in milliseconds between the previous response and the next request.
The total period beetween two requests generated by the <a4j:poll> component is a sum of an"interval" attribute value and server response time.
Default value for "interval" attribute is set to "1000" milliseconds (1 second).
See an example of definition in the "Creating the component with a Page Tag" section.

The "timeout" attribute defines response waiting time in milliseconds.
If a response isn't received during this period a connection is aborted and the next request is sent.
Default value for "timeout" attribute isn't set.

The "enabled" attribute defines should the <a4j:poll> send request or not.
It's necessary to render the <a4j:poll> to apply the current value of "enabled" attribute.
You can use an EL-expression for "enabled" attribute to point to a bean property.
An example of usage of mentioned above attributes is placed below:

The example shows how date and time are updated on a page in compliance with data taken from a server.
The <a4j:poll> componet sends requests to the server every second.
"reRender" attribute of the <a4j:poll> contains poll's own Id.
Hence, it is self rendered for applying the current value of "enabled" attribute.

Notes:

The form around the <a4j:poll> component is required.

To make the <a4j:poll> component send requests periodically when it limitToList is set to "true",
pass the <a4j:poll> ID to it reRender attribute.

6.1.10.1. Description

The main difference between <a4j:push> and <a4j:poll> components is that <a4j:push>
makes request to minimal code only (not to JSF tree) in order to check the presence of messages in the queue.
If the message exists the complete request is performed. The component doesn't poll registered beans
but registers EventListener which receives messages about events.

6.1.10.2. Details of Usage

The <a4j:push> implements reverse Ajax technique.

The bean, for example, could be subscribed to Java Messaging Service
(JMS)
topic or it could be implemented as Message Driven Bean (MDB) in order
to send a message to the <a4j:push> component about an event presence. In the presence of the
event some action occurs.

Thus, a work paradigm with the <a4j:push> component corresponds to an anisochronous model, but not
to pools as for <a4j:poll>component. See the simplest example below:

The example shows how date is updated on a page in compliance with data
taken from a server. In the example "interval" attribute has value "2000". This
attribute defines an interval in milliseconds between the previous
response and the next request. Default value is set to
"1000" milliseconds (1 second). It's
possible to set value equal to "0". In this case
connection is permanent.

The "timeout" attribute defines response waiting time in milliseconds.
If a response isn't received during this period a connection
is aborted and the next request is sent. Default value for "timeout" attribute isn't set. Usage of "interval" and "timeout" attributes gives an opportunity to set short polls of
queue state or long connections.

6.1.11.
<
a4j:queue
>
available since 3.3.0

6.1.11.1. Description

The <a4j:queue> component enqueues set of Ajax requests sent from client.
The RichFaces components with built-in Ajax can reference the queue to optimize Ajax requests.

6.1.11.2. Details of Usage

The RichFaces Queue has four different types: global default, view scoped default, view scoped named and form-based default queue (general Queue principles are good documented in the "Queue Principles" section).
The current section will take closer to the form based queue. The usage of other types is similar.

In order to disable or enable the <a4j:queue> component on the page you can use the "disabled" attribute.

The "requestDelay" attribute defines delay time for all the requests fired by the action components.

The "size" attribute specifies the number of requests that can be stored in the queue at a time.
The attribute helps to prevent server overloading.
It is also possible to determine queue's behaviour when it's size is exceeded.
Use the "sizeExceededBehavior" for this purpose.
There are four possible strategies of exceeded queue's behavior:

"dropNext" drops next request that should be fired

"dropNew" drops the incoming request

"fireNext" immediately fires the next request in line to be fired

"fireNew" immediately fires the incoming request.

Example:

<h:form><a4j:queuesize="2"requestDelay="500"sizeExceededBehavior="dropNext"onsizeexceeded="alert('The size of the queue is exceeded')"/><h:inputTextvalue="#{bean.a}"><a4j:supportevent="onkeyup"/></h:inputText><h:inputTextvalue="#{bean.b}"><a4j:supportevent="onblur"/></h:inputText><h:selectBooleanCheckboxvalue="#{bean.check}"id="checkboxID"><a4j:supportid="checkboxSupport"event="onchange"/></h:selectBooleanCheckbox></h:form>

In this example if the queue has more than 2 requests waiting to be processed the next event will be dropped and a message (the "onsizeexceeded" attribute fires a JavaScript function) saying that the queues is exceeded will be displayed.

The "ignoreDupResponses" attribute that takes a boolean value can also help optimize your Ajax requests.
If set to true, response processing for request will not occur if a similar request is already waiting in the queue. New request will be fired immediately when the response from the previous one returns.

In this case if the sever doesn't respond within a second the request will be aborted.

As you can see the implementation of the queue provides some custom event handlers that you may use to call JavaScript functions.

The "oncomplete"is fired after request completed.
In this event handler request object is be passed as a parameter.
Thus queue is be accessible using request.queue.
And the element which was a source of the request is available using this.

6.1.12.
<
a4j:status
>
available since 3.0.0

6.1.12.1. Description

The <a4j:status> component generates elements for displaying of the current Ajax requests status.
There are two status modes: Ajax request is in process or finished.

6.1.12.2. Details of Usage

There are two ways for the components or containers definition, which Ajax requests status is tracked by a component.

Definition with the "for"
attribute on the <a4j:status> component. Here "for"
attribute should point at an Ajax container (<a4j:region>) id, which requests are tracked by a component.

Definition with the "status"
attribute obtained by any RichFaces library action component. The attribute should point at the <a4j:status> component id. Then this <a4j:status> component shows the status for the request fired from this action component.

The component creates two <span> or <div>
elements depending on attribute "layout"
with content defined for each status, one of the elements (start) is initially hidden. At the beginning of an Ajax request, elements state is inversed, hence the second element is shown and the first is hidden. At the end of a response processing, elements display states return to its initial values.