Event Handling Mimi Opkins CECS 493 Fall 2016

User Events Web applications often need to respond to user events, such as selecting items from a menu or clicking a button. For example, you might want to respond to the selection of a country in an address form by changing the locale and reloading the current page to better accommodate your users. Typically, you register event handlers with components—for example, you might register a value change listener with a menu in a JSF page, like this: In the preceding code, the method binding #{form.countryChanged} references the countryChanged() method of a bean named form. That method is invoked by the JSF implementation after the user makes a selection from the menu. Exactly when that method is invoked is one topic of discussion in this chapter.

Event Types JSF supports four kinds of events: • Value change events • Action events • Phase events • System events

“Firing” Events Value change events are fired by editable value holders—such as h:inputText, h:selectOneRadio, and h:selectManyMenu—when the component’s value changes. Action events are fired by action sources—for example, h:commandButton and h:commandLink—when the button or link is activated. 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 now possible to carry out an action before a view or component is rendered. Keep in mind that all JSF events are executed on the server. When you provide an event handler in a JSF page, you tell the JSF implementation that you want the event to be handled, at the appropriate place in the life cycle, when the server processes the user input from your page.

Events and the JSF Life Cycle Requests in JSF applications are processed by the JSF implementation with a controller servlet, which in turn executes the JSF life cycle Starting with the Apply Request Values phase, the JSF implementation may create events and add them to an event queue during each life cycle phase. After those phases, the JSF implementation broadcasts queued events to registered listeners

Event handling in the JSF life cycle Event listeners can affect the JSF life cycle in one of three ways: 1. Let the life cycle proceed normally. 2. Call the renderResponse() method of the FacesContext class to skip the rest of the life cycle up to Render Response. 3. Call the responseComplete() method of the FacesContext class to skip the rest of the life cycle entirely.

Value Change Events Components in a web application often depend on each other. For example, in the application shown in the next slide, the value of the “State” prompt depends on the “Country” menu’s value. You can keep dependent components in synch with value change events, which are fired by input components after their new value has been validated.

Using value change events

Value Change Listener This application attaches a value change listener to the “Country” menu and uses the onchange attribute to force a form submit after the menu’s value is changed: Here, #{form.countries} is bound to an array of Locale objects. 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:

Value Change Event 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 we add an onchange attribute whose value is submit() to our 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.

Directory structure for the value change example

API UIComponent getComponent() returns the input component that triggered the event. Object getNewValue() returns the component’s new value, after the value has been converted and validated. Object getOldValue() returns the component’s previous value.

valuechange/web/index.xhtml

valuechange/src/java/com/corejsf/RegisterForm.java

valuechange/web/WEB-INF/faces-config.xml

valuechange/src/java/com/corejsf/messages_en_US.properties

valuechange/src/java/com/corejsf/messages_en_CA.properties

Action Events Action events are fired by buttons and links. Action events are fired during the Invoke Application phase, near the end of the life cycle. You can add an action listener to an action source, like this:

Action Listeners vs. Actions 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, the following application uses an action and an action listener to react to mouse clicks by forwarding to a JSF page.

The Rushmore application

Actions If you click on a president’s face, the application forwards to a JSF page with information about that president. Note that an action alone cannot implement that behavior—an action can navigate to the appropriate page, but it cannot determine the appropriate page because it knows nothing about the image button in the user interface or the mouse click. The application uses a button with an image, like this:

Action Listeners When you click a president, a listener—which has access to the mouse click coordinates—determines which president was selected. But the listener cannot affect navigation, so it stores an outcome corresponding to the selected president in an instance field. The action associated with the button uses the outcome to affect navigation: Note that the JSF implementation always invokes action listeners before actions.

Event Listener Tags Up to now, we have added action and value change listeners to components with the actionListener and valueChangeListener attributes, respectively. However, you can also add action and value change listeners to a component with the following tags: • f:actionListener • f:valueChangeListener The f:actionListener and f:valueChangeListener tags are analogous to the actionListener and valueChangeListener attributes. For example, we defined a menu like this:

Listener Tags vs. Attributes Alternatively, we could use f:valueChangeListener, like this: The 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:

Multiple Listeners 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. You can specify multiple listeners with multiple f:actionListener or f:valueChangeListener tags per component. For example, we could add another action listener to our previous example, like this: In the preceding code fragment, the ActionLogger class is a simple action listener that logs action events. If you specify multiple listeners for a component, as we did in the preceding code fragment, 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 The JSF implementation fires events, called phase events, before and after each life cycle phase. Those events are handled by phase listeners. Unlike value change and action listeners that you attach to individual components, a phase listener is attached to the view root. You can specify a phase listener for an individual page with a tag, such as the following, placed anywhere in that page: <f:phaseListener type="com.corejsf.PhaseTracker"/>

System Events JSF supports a fine-grained notification system in which individual components as well as the JSF implementation notify listeners of many potentially interesting events.