AJAX - University of Minnesota Duluth

AJAX

Topics in This Chapter

• “Ajax Fundamentals” on page 530

• “JavaScript Libraries” on page 533

• “Form Completion” on page 534

• “Realtime Validation” on page 537

• “Propagating Client-Side View State” on page 542

• “Direct Web Remoting” on page 543

• “Ajax Components” on page 546

• “Ajax4jsf” on page 554

corejsf2-ch11-VM.fm Page 528 Monday, April 2, 2007 12:22 PM

ChapterChapter

529

11

Web developers have long been mired in the mundane business of form pro-cessing without the means to acheive the high level of interactivity common in desktop applications. Or so we thought. When Google unveiled Google Maps, they proved that web applications can provide rich user interfaces that are just as compelling as desktop applications.

Google Maps also set in motion an incredible wave of innovation whose effects will be felt in the software development community for some time to come. In this chapter we will see some of that innovation in action as we explore using JSF and Ajax (Asynchronous JavaScript with XMLHttpRequest) together to create rich user interfaces. Along the way, we will discuss the following topics:

• Ajax fundamentals (page 530)• Implementing Ajax with a servlet in a JSF application (page 532)• Using JSF phase listeners for more complex Ajax scenarios (page 537)• Form completion (page 534) and realtime validation (page 537)• Accessing UI view state from an Ajax call (page 542)• Dealing with client-side state saving and Ajax (page 542)• Direct Web Remoting (page 543)• Wrapping Ajax in JSF components (page 546)• Using the Ajax4jsf framework (page 554)


Chapter 11 ■ Ajax530

Ajax Fundamentals

Ajax is a simple three-step process:

1. Invoke a URL from JavaScript code on the client.2. Handle the URL on the server and write to the response.3. After the response is complete, integrate the response into the DOM

(Document Object Model).

These steps are almost identical to what JSF does when you click a link, which illicits a request. JSF handles that request on the server by ultimately writing to the response, which overwrites the previous response.

The same applies for Ajax requests, except for the last step. In an Ajax request, we don’t refresh the entire page; instead, we update only part of the page. That subtle difference lets us perform all kinds of interesting interactions that were heretofore unheard of in web applications.

To illustrate the steps in an Ajax request, we now take a look at the application shown in Figure 11–1.

Figure 11–1 Basic Ajax with an XHR object and a servlet


Ajax Fundamentals 531

The application shown in Figure 11–1 performs an Ajax request to obtain the current date and time from the server. Subsequently, on the client, the applica-tion integrates that response into the web page’s DOM. That causes the date to update without refreshing the entire page.

Here is how it works. First, we have a DIV, which is initially empty. After the request, we update that DIV’s inner HTML. Here is the DIV and the button that sets everything in motion:

<h:commandButton type="button" value="#{msgs.buttonPrompt}" onclick="showDateAndTime();" styleClass="button"/>

<div id="dateDIV" class="dateDiv"/>

Notice the button’s type is button, which means it is a push button and not a submit button. When a user activates that button, JSF does not submit the sur-rounding form; instead, it calls the JavaScript showDateAndTime function, which looks like this:

<script type="text/javascript" language="Javascript1.1"></script>

Once again, we are using Prototype in this example. Prototype greatly simpli-fies our JavaScript, mainly through the use of Prototype’s Ajax.Request object, which executes the Ajax request, and the $() function, which is a handy short-cut for window.document.getElementById().

In the preceding code fragment, we are also using the Fade Anything Tech-nique’s Fat JavaScript object to fade both the city and state fields after we update them.

The URL that we used for the Ajax call—zipChanged.ajax—is handled on the server by a servlet:

public class AjaxServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); response.setHeader("Cache-Control", "no-cache"); response.setStatus(HttpServletResponse.SC_OK); response.getWriter().write(getResponseForZip(request.getParameter("zip"))); }

private String getResponseForZip(String zip) { return "97402".equals(zip) ? "Eugene,Oregon" : "NO DATA,NO DATA"; }}


Realtime Validation 537

If the servlet finds the zip code in our database, it writes a simple string to the response with this format: City,State. If we do not find a match, we return this instead: NO DATA,NO DATA. When the request is finished, we parse that response string and set the inner HTML of the city and state text fields to their respective values. Of course, in a real application, you might opt for a more robust database of zip codes.

NOTE: The preceding form completion example requires very little knowl-edge of JSF, other than attaching JavaScript event handlers to JSF compo-nents (with DHTML attributes provided by the tags in the HTML tag library) and knowing how JSF creates client identifiers from component IDs. As that example illustrates, simple Ajax interactions can be easily implemented in a JSF application without much knowledge of JSF itself.

Realtime Validation

As we saw in “Form Completion” on page 534, you can implement basic Ajax in a JSF application with little more than a servlet and a few lines of JavaScript. In this example, we will implement realtime validation, which will give us the opportunity to explore some of the more complex interactions between Ajax and JSF.

The application shown in Figure 11–3 performs realtime validation. When the user enters the fifth character of the zip code, we execute an Ajax request to validate those five digits.

Figure 11–3 Realtime validation



On the server, we obtain a reference to the component that represents the zip code field, and iterate over that component’s validators, invoking each in turn. If any of the validators attached to the component throws an exception, we catch the exception, write an error to the response, and terminate the request.

Subsequently, back on the client, we display that error response in a DIV. That scenario is shown in Figure 11–3, where the user has entered an invalid zip code.

Here is the pertinent JSP:

<html> <f:view> <body> ... <p><div id="errors" class="errors"></div></p>

<h:form id="form"> <h:panelGrid columns="2"> ... <h:inputText id="zip" size="5" value="#{bb.zip}" onfocus="clearCityAndStateFields();" onblur="zipBlurred(this.value);" onkeyup="zipChanged(this.value);"> <f:validator validatorId="com.clarity.ZipCodeValidator"/> </h:inputText> ... </h:panelGrid> </h:form> </body> </f:view></html>

We have wired the onkeyup event for our zip code field to a function called zipChanged, which we discuss momentarily. We have also added a custom valida-tor to the zip code component. That validator recognizes only the 97402 zip code; all other zip codes are considered invalid. Finally, we have added our errors DIV, which is initially empty.

This realtime validation example is more complex than the application dis-cussed in “Form Completion” on page 534 because realtime validation forces us to access view state, meaning the component tree, for the JSP page.



Remember that we need to get a reference to the zip code component and iter-ate over its validators. To do that, we need access to the view state, which is only available to POST requests. Because of that restriction, we issue a POST request:

<script type="text/javascript" language="Javascript1.1"> <f:validateLength minimum="5" maximum="5"/>

<f:validator validatorId="com.corejsf.ZipcodeValidator"/>

 <a4j:support event="onblur" immediate="true" actionListener="#{bb.validateZip}" reRender="city, state, errorMessage"/>

</h:inputText>

<h:outputText id="errorMessage" value="#{bb.errorMessage}" style="color: red; font-style: italic;"/> </h:panelGroup>

<h:outputLabel for="city" value="#{msgs.cityPrompt}"/>


Ajax4jsf 563

<h:inputText id="city" binding="#{bb.cityInput}" size="25" value="#{bb.city}"/>

<h:outputLabel for="state" value="#{msgs.statePrompt}"/> <h:inputText id="state" binding="#{bb.stateInput}" size="15" value="#{bb.state}"/> ... </h:panelGroup> </h:panelGrid> </h:form> </body> </f:view></html>

The first thing to notice is that we have used the a4j:status tag to display the busy indicator. You can specify start and stop facets for that tag, and when any Ajax call initiated by Ajax4jsf occurs, Ajax4jsf will display the start facet’s component. When the call completes, Ajax4jsf will display the stop facet’s component.

In our case, we did not specify a stop facet, and so Ajax4jsf will simply remove the start facet’s component from the page when the call is complete.

Second, notice that the zip code field is required, and that we have added a length validator and our custom validator to that input component.

Third—and here is part one of the monkey wrench—is the fact the we have made the a4j:support tag inside the zip code component immediate. If we neglect to do that, our example will no longer work. To find out why, other than reading the comment in the preceding JSP page, we take a look at our backing bean’s implementation:


import javax.faces.event.ActionEvent;import javax.faces.context.FacesContext;import javax.faces.component.UIInput;import javax.faces.application.FacesMessage;import java.util.Iterator;

public class BackingBean { private String zip; private String city; private String state;



private String errorMessage = null;

public String getState() { return state; } public void setState(String state) { this.state = state; } public String getCity() { return city; } public void setCity(String city) { this.city = city; } public String getZip() { return zip; } public void setZip(String zip) { this.zip = zip; }

// Error message setter & getter, plus a clear error msg method public String getErrorMessage() { return errorMessage; } public void setErrorMessage(String errorMessage) { this.errorMessage = errorMessage; } public void clearErrorMessage(ActionEvent e) { errorMessage = null; }

// AJAX

/* cityInput and stateInput are set by component * bindings in the view: * * <h:inputText id="city" binding="#{bb.cityInput}" * size="25" * value="#{bb.city}"/> * * <h:inputText id="state" binding="#{bb.stateInput}" * size="15" * value="#{bb.state}"/> * */ private UIInput cityInput = null; // cityInput public UIInput getCityInput() { return cityInput; } public void setCityInput(UIInput cityInput) { this.cityInput = cityInput; }

private UIInput stateInput = null; // stateInput public UIInput getStateInput() { return stateInput; } public void setStateInput(UIInput stateInput) {


Ajax4jsf 565

this.stateInput = stateInput; }

/* validateZip is called by Ajax4jsf in response to * an onblur in the zip code textfield: * * <a4j:support event="onblur" * immediate="true" * actionListener="#{bb.validateZip}" * reRender="city, state, errorMessage"/> */ public void validateZip(ActionEvent e) { // This executes too fast to see the busy indicator in // the view, so we slow it down try { Thread.sleep(250); } catch (InterruptedException e1) { e1.printStackTrace(); }

UIInput input = (UIInput)e.getComponent() // Ajax4jsf comp .getParent(); // input comp if (input != null) { String zip = (String)input.getSubmittedValue(); if (zip != null) { // set city and state properties according // to the zip field's submitted value setCityAndState(zip);

// validate the zip field FacesContext fc = FacesContext.getCurrentInstance(); input.validate(fc); // iterates over input's validators if ( ! input.isValid()) setErrorMessage(fc, input);

// Force JSF to refresh city and state input fields. // If an input component's submitted value is not null, // JSF will not refresh the field. cityInput.setSubmittedValue(null); stateInput.setSubmittedValue(null); } } } private void setErrorMessage(FacesContext fc, UIInput input) { // set errorMessage to the first message for the zip field



Iterator it = fc.getMessages(input.getClientId(fc)); if (it.hasNext()) { FacesMessage facesMessage = (FacesMessage)it.next(); errorMessage = facesMessage.getSummary(); } } private void setCityAndState(String zip) { String cityAndState = ZipcodeDatabase.getCityAndState(zip); if (cityAndState != null) { // zip recognized String[] cityStateArray = cityAndState.split(","); setCity(cityStateArray[0]); setState(cityStateArray[1]); } else { // unknown zip with 5 chars if (zip.length() == 5) { setCity ("no data for " + zip); setState("no data for " + zip); } else { // unknown zip without 5 chars setCity(null); setState(null); } } }}

Remember that the a4j:support tag adds an action listener to the JSF life cycle. That is pretty evident considering that the name of the tag’s corresponding attribute is actionListener. But the consequences of that listener may not be so readily apparent.

As the Ajax call goes through the JSF life cycle, JSF will validate our zip code component about halfway through the life cycle in the Process Validations phase. If validation fails, JSF immediately proceeds to the Render Response phase of the life cycle to redisplay the page, which is standard JSF behavior whenever validation fails. Realize that JSF itself has no idea that this is an Ajax call, so it cycles through the life cycle as though we had submitted the form in which the zip code component is contained.

If validation fails in the Process Validations phase and JSF proceeds to the Ren-der Response phase as a result, it will skip any action listeners associated with the call, because action listeners are invoked just before the Render Response phase. So, we make the action listener immediate, which means JSF will invoke the listener at the front of the life cycle (after the Apply Request Values phase), and subsequently proceed to the Render Response phase. Therefore, if we don’t


Ajax4jsf 567

make our action listener immediate, by specifying immediate=true for our a4j:status component, our action listener will never be invoked.

Now for part two of the monkey wrench, which is more insidious than part one. Notice that our action listener invokes the validate method on our zip code component. If the component is invalid after that call, we know that validation failed, and we set the errorMessage property of the backing bean accordingly, which is what we display in the view.

To recap so far: We use the a4j:support tag to add an action listener to the JSF life cycle when Ajax4jsf makes its Ajax call after we leave the zip code field. Our action listener manually validates the input field, and it must be immediate to keep JSF from performing validation and skipping our listener when vali-dation fails.

One more part to the monkey wrench puzzle: When JSF performs validation, and validation succeeds for all input components, JSF sets all the input compo-nent’s submitted values (which is what the user typed into the fields) to null. On the other hand, if validation fails for one or more inputs, JSF leaves the submitted values as they were.

When JSF subsequently rerenders the page, either because validation failed or because there was no navigation specified for the form submit, JSF checks the input components to see if their submitted values are null; if so, it refetches the component’s values. However, if the submitted values are not null, meaning that validation failed, JSF does not repopulate the fields by fetching their asso-ciated values; instead, it redisplays those submitted values. That is how JSF retains erroneous values in input components when validation fails, which is desired behavior.

Because we are invoking validation manually, our input component’s submit-ted values are never set to null when validation succeeds, as would be the case if JSF were invoking validation. So we must do that manually for the city and state fields to display Eugene and Oregon, respectively, when validation succeeds. To do that, we use component bindings and call setSubmittedValue(null) on the city and state components.

This exercise should convince you that using Ajax4jsf is not as simple as our form completion with Ajax4jsf example in the preceding section might lead you to believe. You must have a solid grasp of the JSF life cycle and what JSF does during that life cycle. For that, you will probably need a good book on JSF, and thankfully, you have one. You must also understand how Ajax4jsf imple-ments Ajax. For example, Ajax4jsf’s a4j:support tag does not pull the rug out from under JSF by invoking responseComplete on the Faces context, as we did



early on in this chapter. Instead, the life cycle proceeds as it normally would with the addition of an action listener, and it is vital that you understand the ramifications of that design choice.

For completeness, we offer listings of our custom zip code validator, and a zip code database used by our backing bean. Here is the validator:


import com.corejsf.util.Messages;

import javax.faces.context.FacesContext;import javax.faces.component.UIComponent;import javax.faces.validator.ValidatorException;import javax.faces.validator.Validator;

public class ZipcodeValidator implements Validator { public void validate(FacesContext fc, UIComponent c, Object zip) throws ValidatorException { String cityAndState = ZipcodeDatabase .getCityAndState((String)zip);

if (cityAndState == null) { throw new ValidatorException( Messages.getMessage("com.corejsf.messages", "badZip")); } }}

And here is the database:


public class ZipcodeDatabase { public static String getCityAndState(String zip) { if ("97402".equals(zip)) return "Eugene,Oregon"; else return null; }}

Documents

AJAX - University of Minnesota Duluth