This is a third post in Learning JSF 2 series. The first one on Managed Beans can be found here and second one on navigation can be found here.
As you probably know JSF 2 is a major upgrade over JSF 1.2. One of the major additions to this version of JSF is standard Ajax support. This article covers Ajax features in JSF 2. If you are familiar with RichFaces and specifically the a4j:support tag then learning how to use Ajax features in JSF 2 is going to be very easy. Many concepts and features are being carried over from RichFaces. Let’s start.
JSF 2 comes with one tag that provides Ajax functionality. The tag is called f:ajax (sounds familiar to a4j:support – right?) When I do RichFaces trainings, I like to divide the core ideas into three parts: sending an Ajax request, partial view rendering and partial view processing. I will use the same approach here.
Sending an Ajax request
JSF comes with one tag to send an Ajax request, the tag is called f:ajax. This tag is actually a client side behavior (here is a great post by Andy Schwartz on JSF 2 client behaviors). Being a behavior implies it’s never just used by itself on a page, it is always added as a child tag (behavior) to another UI component (or can even wrap several components). Let’s use a small echo application to demonstrate usage of this tag.
Code snippet above takes care of firing an Ajax request based on onkeyup event. Notice the actual event name is keyup. This takes care of firing an Ajax request. Next we need to figure out how to do partial view rendering.
| Attribute | Description |
|---|---|
| event | String on which event Ajax request will be fired. If not specified, a default behavior based on parent component will be applied. The default event is action for ActionSource (ie: button) components and valueChange for EditableValueHolder components (ie: input). action and valueChange are actual String values that can be applied applied event attribute. |
Note: In RichFaces 3.x, you specify the event with onevent, for example onkeyp. In JSF 2, you only specify the actual action: keyup.
Partial view rendering
With JSF 1.2 (and without RichFaces) every request would render the entire view back to us. That was simple, we didn’t have to worry which parts of the JSF view we want to be updated. Of course the basic concept behind Ajax is to only update those parts of the page that we actually need to. In order to accomplish this, we should only render those components on the server whose markup we want to update in browser. What all this means is we now need to specify which components in JSF view we want to render back. Partial view is still rendered on the server. Some updated portion is sent as XML to the browser where the DOM is updated. Our example is rather simple, there is just one component with id text. f:ajax tag has render attribute which points to id’s of components to be rendered (or rerendered) back. It could also take an EL expression. Adding it to our example, it looks like this:
If you have been using RichFaces, than the same attribute in RichFaces is called reRender. The event that is specified via event attribute must be an event that the parent component supports. If you look at the generated HTML, you will see something like this:
If you specify an event that is not available on the parent component, an error message will be displayed when you run the page.
That’s it. Here is the bean code in case you want to run this page:
@ManagedBean(name = "bean")
public class Bean {
private String text; // getter and setter
...
}
Let’s say we also want to show and update a counter that shows the length of a string we entered. Adding new property to bean:
private Integer count; // getter and setter
Also adding Ajax listener to do the counting, notice that method takes a new AjaxBehaviorEvent object:
public void countListener(AjaxBehaviorEvent event) {
count = text.length();
}
| Attribute | Description |
|---|---|
| listener | Listener method to invoke during Ajax request. |
Updating the page:
Notice that we added count id to render attribute. You use space as a separator for id’s.
In our examples above we actually specified on which even to fire an Ajax request. As it turns out we don’t have to specify an event. If we don’t specify one, each UI component has a default event on which Ajax request would be send. Taking h:inputText, the default Ajax event is onchange. Our example would almost work however, instead of onkeyup, you would now have to tab out or click outside the input field to fire the Ajax request: So, we could have written our example like this (without event attribute):
| Attribute | Description |
|---|---|
| render | Determines id’s of components to be rendered. |
In our example, render pointed to actual component id we want to render back. render attribute could be set to the following values:
| Possible values for render attribute | Description |
|---|---|
| @all | Render all components in view |
| @none | Render no components in view (this is also the default value if render is not specified) |
| @this | Render only this component, the component that triggered the Ajax request |
| @form | Render all components within this form (from which Ajax request was fired) |
| id’s | One or more id’s of components to be rendered |
| EL | EL expression which resolves to Collection of Strings |
render could also point to EL expression. In this case it’s possible to determine which components to render in run time. Here is how it works when using EL:
- You bind render=”#{bean.renderComponents}”. Initial page is rendered. #{bean.renderComponents} is resolved during page rendering, for example to id’s compId1 and compId2.
- On next Ajax request, compId1 and compId2 will be rerendered. During this request, #{bean.renderComponents} could be changed in runtime. For example, it is now set to compId3 and compId4. You also have to remember to rerender this control (in order to update the ids)
- Page is rendered (from step 3). Values of compId3 and compId4 are now present (rendered) in the page.
- On next Ajax request, components with id’s compId3 and compId4 will be rerendered.
Note: this behavior is slightly different than what you get do in RichFaces 3. In RichFaces reRender attribute when bound to an EL expression is resolved in the current request.
It’s also possible to issue Ajax requests programmatically using the jsf.ajax.request() JavaScript API:
...
A few things to look for. First, you need to include jsf.js file which provides all the JavaScript functionality. Second, for render you need to use client id (not just component id).
Let’s look at an example using a button:
Java bean:
public class Bean {
public Date getNow () {
return (new Date());
}
}
In example above, we are adding Ajax behavior to standard JSF button. We specified both event and render. But, the example could also be rewritten like this:
So far we covered sending an Ajax request and partial view rendering. Let’s now cover the third part: partial view processing.
Partial view processing
In JSF 1.x (and without RichFaces) when a form was submitted, the entire form was processed on the server. Processed means that all components went through phases Apply Request Values, Process Validation and Update Model. When Ajax, there are situations when you don’t want to process all the components in the form. To control which components will get processed, we use execute attribute on f:ajax tag.
In above example, when button is clicked an Ajax request is fired and the entire form will be processed on the server.
| Attribute | Description |
|---|---|
| execute | Determines id’s of components to be processed on server |
| Possible values for execute attribute | Description |
|---|---|
| @all | Process all components in view |
| @none | Process no components |
| @this | Process only this component, the component that triggered the Ajax request (default) |
| @form | Process all components within this form (from which Ajax request was fired) |
| id’s | Implicit id’s of components to be processed, space separated |
| EL | Must resolve to Collection of Strings |
More examples
Let’s look at more examples using f:ajax tag.
If you have multiple controls that fire an Ajax request you could next f:ajax inside each one. Alternatively, you can also put f:ajax around those controls:
From example above, f:ajax will be added to each control using their default Ajax events:
| h:panelGrid | no default behavior, so no Ajax event will be added |
| h:selectBooleanCheckbox | onchange |
| h:inputText | onchange |
| h:commandButton | onclick |
We can also specify an event which would then be applied to children components:
In example above, onclick event will be added to panelGrid, inputText and commandButton. commandButton would also have onfocus event applied to it.
In example above we are applying the default valueChange event. It’s not possible to apply valueChange to panelGrid, so nothing will be applied to it. h:selectBooleanCheckbox and h:inputText will have valueChange applied to both. As valueChange is not a valid event for h:commanButton, the event will not be applied and h:commandButton will have only onfocus applied to it.
Hopefully this gives you a good introduction how to use f:ajax tag in JSF 2.
RichFaces
If you have been using RichFaces and specifically a4j:support tag then you might be wondering what’s going to happen to it? In RichFaces 4 (JSF 2 based) a4j:support is going to be renamed to a4j:ajax to match the standard tag name. a4j:ajax will use the standard f:ajax under the covers but will also provide numerous advanced features and attributes that you get today in RichFaces and which are not available in JSF 2. You will also have tags such as a4j:poll, a4j:jsFunction, a4j:outputPanel which are not available in JSF 2 and which give you more power and flexibility.
I want to thank Nick Belaevski from RichFaces team (Exadel) for doing technical review for this article.
Max Katz 
Leave a comment