JBoss.orgCommunity Documentation

Chapter 5. Basic concepts of the RichFaces Framework

5.1. Introduction
5.2. RichFaces Architecture Overview
5.3. Limitations and Rules
5.4. Ajax Request Optimization
5.4.1. Re-Rendering
5.4.2. Queue and Traffic Flood Protection
5.4.3. Data Processing Options
5.4.4. Action and Navigation
5.4.5. JavaScript Interactions
5.4.6. Iteration components Ajax attributes
5.4.7. Other useful attributes
5.5. How To...
5.5.1. Send an Ajax request
5.5.2. Decide What to Send
5.5.3. Decide What to Change
5.5.4. Decide what to process
5.6. Filter Configuration
5.7. Scripts and Styles Load Strategy
5.8. Request Errors and Session Expiration Handling
5.8.1. Request Errors Handling
5.8.2. Session Expired Handling
5.9. Skinnability
5.9.1. Why Skinnability
5.9.2. Using Skinnability
5.9.3. Example
5.9.4. Skin Parameters Tables in RichFaces
5.9.5. Creating and Using Your Own Skin File
5.9.6. Built-in skinnability in RichFaces
5.9.7. Standard controls skinning

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:


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.

Next figure lists several important elements of the RichFaces framework


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:


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.


AJAX Action Components

There are Ajax Action Components: AjaxCommandButton, AjaxCommandLink, AjaxPoll and AjaxSupport 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.

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

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.

A simple example is placed below:


...
        <a4j:commandButton value="update" reRender="infoBlock"/>
            ...
        <h:panelGrid id="infoBlock">
            ...
        </h:panelGrid>
...

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):


...
    <h:form id="form1">
        ...
        <a4j: commandButton value="Usual Way" reRender="infoBlock, infoBlock2" />
        <a4j:commandButton value="Shortcut" reRender=":infoBlockl,:sv:infoBlock2" />
        ...
    </h:form>
    <h:panelGrid id="infoBlock">
        ...
    </h:panelGrid>
    ...
    <f:subview id="sv">
      <h:panelGrid id="infoBlock2">
        ...
      </h:panelGrid>
      ...
    </f:subview>
...

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.


...
     <a4j:outputPanel ajaxRendered="true">
        <h:messages />
    </a4j:outputPanel>
...

"limitToList" attribute allows to dismiss the behavior of the <a4j:outputPanel> "ajaxRendered" attribute. "limitToList" = "false" 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:


...
    <h:form>
       <h:inputText value="#{person.name}">
            <a4j:support event="onkeyup" reRender="test" limitToList="true"/>
        </h:inputText>
        <h:outputText value="#{person.name}" id="test"/>
    </form>
...

"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.


...
    <h:inputText value="#{userBean.name}">
        <a4j:support event="onkeyup" eventsQueue="foo" reRender="bar" />
    </h:inputText>
...

"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.

More information can be found on the RichFaces Users Forum.

"timeout" attribute is used for setting response waiting time on a particular request. If a response is not received during this time, the request is aborted.

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:action> param 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:


...
    <h:form>
        <h:inputText value="#{person.name}">
            <a4j:support event="onkeyup" reRender="test" ajaxSingle="true"/>
        </h:inputText>
      <h:inputText value="#{person.middleName}"/>
    </form>
...

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.

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" attribute 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 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 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.

"oncomplete" attribute allows to invoke the JavaScript code right after the Ajax Response is returned back and the DOM tree of the browser is updated. Richfaces registers the code for further invocation of XMLHTTP request object before an Ajax request is sent. This means the code will not be changed during processing of the request on the server if you use JSF EL value binding. Also, you cannot use "this'" inside the code, because it will not point the component where Ajax request was initiated.

"onbeforedomupdate" attrubute 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:


...
    <a4j:commandButton value="Update" data="#{userBean.name}" oncomplete="showTheName(data.name)" />
...

Richfaces allows to serialize not only primitive types into JSON format, but also complex types including arrays and collections. The beans should be serializable to be refered with "data" .

There is a number of useful functions which can be used in JavaScript:

"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.


...
    <a4j:region id="extr">
        <h:form>
            <h:outputText value="Status:" />
            <a4j:status id="commonstatus" startText="In Progress...." stopText=""/>
            <h:panelGrid columns="2">
                <h:outputText value="Name"/>
                <h:inputText id="name" value="#{userBean.name}">
                    <a4j:support event="onkeyup" reRender="out" />
                </h:inputText>
                <h:outputText value="Job"/>
                <a4j:region  id="intr">
                    <h:inputText id="job" value="#{userBean.job}">
                        <a4j:support event="onkeyup"  reRender="out" status="commonstatus"/>
                   </h:inputText>
                </a4j:region>
            </h:panelGrid>

            <a4j:region>
                <h:outputText id="out" value="Name: #{userBean.name}, Job: #{userBean.job}" />
                <br />
                <a4j:commandButton ajaxSingle="true" value="Clean Up Form" reRender="name, job, out"  status="commonstatus">
                    <a4j:actionparam name="n" value=""  assignTo="#{userBean.name}" />
                    <a4j:actionparam name="j" value=""  assignTo="#{userBean.job}" />
                </a4j:commandButton>
            </a4j:region>
        </h:form>
    </a4j:region>
...

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.

More information could be found here.

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

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.

Example:


...
    <filter>
        <display-name>RichFaces Filter</display-name>
        <filter-name>richfaces</filter-name>
        <filter-class>org.ajax4jsf.Filter</filter-class>
    </filter>
...

In 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" 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.

No correction.

An example of configuration is placed below.

Example:


...
    <context-param>
        <param-name>org.ajax4jsf.xmlparser.ORDER</param-name>
        <param-value>NONE,NEKO,TIDY</param-value>
    </context-param>
 
    <context-param>
        <param-name>org.ajax4jsf.xmlparser.NONE</param-name>
        <param-value>/pages/performance\.xhtml,/pages/default.*\.xhtml</param-value>
    </context-param>

    <context-param>
        <param-name>org.ajax4jsf.xmlparser.NEKO</param-name>
        <param-value>/pages/repeat\.xhtml</param-value>
    </context-param>
    
    <filter> 
        <display-name>RichFaces Filter</display-name> 
        <filter-name>richfaces</filter-name> 
        <filter-class>org.ajax4jsf.Filter</filter-class> 
    </filter>
    
    <filter-mapping> 
        <filter-name>richfaces</filter-name> 
        <servlet-name>Faces Servlet</servlet-name>
        <dispatcher>FORWARD</dispatcher> 
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>INCLUDE</dispatcher> 
    </filter-mapping>
...

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:


<param-value>/pages/performance\.xhtml,/pages/default.*\.xhtml</param-value>,

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).

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.


...
    <context-param>
          <param-name>org.richfaces.LoadScriptStrategy</param-name>
          <param-value>ALL</param-value>
    </context-param>    
...

If you do not declare the org.richfaces.LoadScriptStrategy in the web.xml, it equals to:


...
    <context-param>
        <param-name>org.richfaces.LoadScriptStrategy</param-name>
        <param-value>DEFAULT</param-value>
    </context-param>    
...

The third possible value is "NONE". You have no a special reason to use it unless you obtain the newest (or modified) version of the script and want to include it manually in a page header.

org.richfaces.LoadStyleStrategy

The following declaration allows to load only one integrated style sheet file.


...
    <context-param>
          <param-name>org.richfaces.LoadStyleStrategy</param-name>
          <param-value>ALL</param-value>
    </context-param>
...

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.

For more information see RichFaces User Forum.

RichFaces allows to redefine standard handlers responsible for processing of different exceptional situations. It helps to define own JavaScript, which is executed when these situations occur.

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 theRichFaces project and realized 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.

RichFaces provides eight predefined skin parameters (skins) at the simplest level of common customization:

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".



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.

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:

    Example:

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

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:

http://livedemo.exadel.com/richfaces-demo/

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:

Extra information on custom renderers creation can be found at:

http://java.sun.com/javaee/javaserverfaces/reference/docs/index.html

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 element' 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, while skinning is based on detecting User Agent. If User Agent is not detected, Advanced level is used.

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 can be initialized in two ways:

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

  • adding org.richfaces.CONTROL_SKINNING_CLASSES parameter to web.xml file. Possible values "enable" and "disable". Implementation of this method implies the provision of several style classes for different types of elements. The style classes have predefined names. Application developer should manually assign classes to controls that needs skinning or assign class to an element that contains controls.

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

  • Basic elements nested inside element having rich-container class, e.g.:

    Example:

    
    ...
    .rich-container select {
       
    //class content
    }
    ...
  • Elements that has class name corresponding to one of the basic elements name/type mapped by the following scheme rich-<elementName>[-<elementType>]. See the example:

    Example:

    
    ...
    .rich-select {
      
    //class content
    }

    .rich-input-text {
      
    //class content
    }

    ...

    Note:

    a elements have classes based on "link" and pseudo class name, e.g.: rich-link, rich-link-hover, rich-link-visited