On Java Development

All things related to Java development, from the perspective of a caveman.

JSF Event Processing

without comments


This brief post highlights some of the behavior differences between JSF’s Value Change and Action events

Value Change Events

Value change events are fired by editable value holders ( h:inputText, h:selectOneRadio, and h:selectManyMenu) when the component’s value changes.

Consider a screen that has a select list allowing the user to select the country name which is used to set the form’s locale setting. The component’s code is shown below.

When a user selects a country from the menu, the JavaScript submit function is invoked to submit the menu’s form, which subsequently invokes the JSF life cycle. After the Process Validations phase, the JSF implementation invokes the form bean’s countryChanged method. That method changes the view root’s locale, according to the new country value:

Like all value change listeners, the preceding listener is passed a value change event. The listener uses that event to access the component’s new value.

One more thing is noteworthy about this example. Notice that an onchange attribute whose value is submit() was added to the h:selectOneMenu tag. Setting that attribute means that the JavaScript submit function will be invoked whenever someone changes the selected value of the menu, which causes the surrounding form to be submitted.

That form submit is crucial because the JSF implementation handles all events on the server. If you take out the onchange attribute, the form will not be submitted when the selected menu item is changed, meaning that the JSF life cycle will never be invoked, our value change listener will never be called, and the locale will never be changed.

You may find it odd that JSF handles all events on the server, but remember that you can handle events on the client if you wish by attaching JavaScript to components with attributes, such as onblur, onfocus, onclick, and so on.


Action Events

Action events are fired by action sources ( h:commandButton and h:commandLink when the button or link is activated.

Command components submit requests when they are activated, so there is no need to use onchange to force form submits. When you activate a button or link, the surrounding form is submitted and the JSF implementation subsequently fires action events.

It is important to distinguish between action listeners and actions. In a nutshell, actions are designed for business logic and participate in navigation handling, whereas action listeners typically perform user interface logic and do not participate in navigation handling. Action listeners sometimes work in concert with actions when an action needs information about the user interface. For example, an action and an action listener can be used to react to mouse clicks by forwarding to a JSF page.

Shown below is the xhtml coding for a series of menu options. Note that the RichFaces toolbar has been wrapped within a form so that the action event methods associated with each option is called.

Below are the associated action event methods.


Event Listeners

Essentially, the f:actionListener and f:valueChangeListener tags are analogous to the actionListener and valueChangeListener attributes. As an example, a selectOneMenu could be coded as

or as

The f:actionListener and f:valueChangeListener tags have one advantage over the attributes: Tags let you attach multiple listeners to a single component.

Notice the difference between the values specified for the valueChangeListener attribute and the f:valueChangeListener tag in the preceding code. The former specifies a method binding, whereas the latter specifies a Java class. For example, the class referred to in the previous code fragment looks like this:

The class implements the ValueChangeListener interface. That class defines a single method: void processValueChange(ValueChangeEvent).

The f:actionListener tag is analogous to f:valueChangeListener—the former also has a type attribute that specifies a class name; the class must implement the ActionListener interface.

Shown below is a command button using the f:actionListener tag.

Action listener classes must implement the ActionListener interface, which defines a processAction method, so in the preceding code fragment, JSF will call RushmoreListener.processAction after the image button is activated.

As mentioned, you can specify multiple listeners with multiple f:actionListener or f:valueChangeListener tags per component.

In the above example, the ActionLogger class is a simple action listener that logs action events. If you specify multiple listeners for a component, the listeners are invoked in the following order:

  1. The listener specified by the listener attribute
  2. Listeners specified by listener tags, in the order in which they are declared


Phase Events

Phase events are routinely fired by the JSF life cycle. JSF 2.0 adds a large number of system events. Some of the system events are of interest to application programmers. For example, it is possible to carry out an action before a view or component is rendered.

Source: Core Java Server Faces, 3rd Edition 2010


Written by admin

May 19th, 2014 at 4:35 am

Posted in JSF 2

Leave a Reply

You must be logged in to post a comment.