AJAX basics with process and update

PrimeFaces provides Partial Page Rendering (PPR) and the view-processing feature based on standard JSF 2 APIs to enable choosing what to process in the JSF life cycle and what to render in the end with AJAX. PrimeFaces AJAX Framework is based on standard server-side APIs of JSF 2. On the client side, rather than using the client-side API implementations of JSF, such as Mojarra or MyFaces, PrimeFaces scripts are based on the jQuery JavaScript library, which is well tested and widely adopted.

How to do it...

We can create a simple page with a command button to update a string property with the current time in milliseconds that is created on the server side and output text to show the value of that string property, as follows:

<p:commandButton update="display" action="#{basicPPRBean.updateValue}" value="Update" />
<h:outputText id="display" value="#{basicPPRBean.value}"/>

If we want to update multiple components with the same trigger mechanism, we can provide the ID's of the components to the update attribute by providing them with a space, comma, or both, as follows:

<p:commandButton update="display1,display2" />
<p:commandButton update="display1 display2" />
<p:commandButton update="display1,display2 display3" />

In addition, there are reserved keywords that are used for a partial update. We can also make use of these keywords along with the ID's of the components, as described in the following table. Some of them come with the JSF standard, and PrimeFaces extends this list with custom keywords. Here's the table we talked about:

Keyword	JSF/PrimeFaces	Description
@this	JSF	The component that triggers the PPR is updated
@form	JSF	The encapsulating form of the PPR trigger is updated
@none	JSF	PPR does not change the DOM with an AJAX response
@all	JSF	The whole document is updated as in non-AJAX requests
@parent	PrimeFaces	The parent of the PPR trigger is updated
@composite	PrimeFaces	This is the closest composite component ancestor
@namingcontainer	PrimeFaces	This is the closest naming container ancestor of the current component
@next	PrimeFaces	This is the next sibling
@previous	PrimeFaces	This is the previous sibling
@child(n)	PrimeFaces	This is the nth child
@widgetVar(name)	PrimeFaces	This is a component stated with a given widget variable name

The keywords are a server-side part of the PrimeFaces Search Expression Framework (SEF), which provides both server-side and client-side extensions to make it easier to reference components. We can also update a component that resides in a different naming container from the component that triggers the update. In order to achieve this, we need to specify the absolute component identifier of the component that needs to be updated. An example of this could be the following:

<h:form id="form1">
  <p:commandButton update=":form2:display" 
    action="#{basicPPRBean.updateValue}" value="Update"/>
</h:form>

<h:form id="form2">
  <h:outputText id="display" value="#{basicPPRBean.value}"/>
</h:form>

@Named
@ViewScoped
public class BasicPPRBean implements Serializable {

  private String value;

  public String updateValue() {
    value = String.valueOf(System.currentTimeMillis());
    return null;
  }

  // getter / setter

}

PrimeFaces also provides partial processing, which executes the JSF life cycle phases—apply request values, process validations, update model, and invoke application—for determined components with the process attribute. This provides the ability to do group validation on the JSF pages easily. Mostly group validation needs arise in situations where different values need to be validated in the same form, depending on an action that gets executed. By grouping components for validation, errors that would arise from other components when the page has been submitted can be overcome easily. Components such as commandButton, commandLink, autoComplete, fileUpload, and many others provide this attribute to process partially instead of processing the whole view.

Partial processing could become very handy in cases where a drop-down list needs to be populated upon a selection on another dropdown and where there is an input field on the page with the required attribute set to true. This approach also makes immediate subforms and regions obsolete. It will also prevent submission of the whole page; thus, this will result in lightweight requests. Without partially processing the view for the dropdowns, a selection on one of the dropdowns will result in a validation error on the required field. A working example for this is shown in the following code snippet:

<h:outputText value="Country: " />
<h:selectOneMenu id="countries" value="#{partialProcessingBean.country}">
<f:selectItems value="#{partialProcessingBean.countries}" />
  <p:ajax listener= "#{partialProcessingBean.handleCountryChange}"
    event="change" update="cities" process="@this"/>
</h:selectOneMenu>

<h:outputText value="City: " />
<h:selectOneMenu id="cities" value="#{partialProcessingBean.city}">
  <f:selectItems value="#{partialProcessingBean.cities}" />
</h:selectOneMenu>

<h:outputText value="Email: " />
<h:inputText value="#{partialProcessingBean.email}" required="true" />

With this partial processing mechanism, when a user changes the country, the cities of that country will be populated in the dropdown regardless of whether any input exists for the email field or not.

How it works…

As illustrated in the partial processing example to update a component in a different naming container, <p:commandButton> is updating the <h:outputText> component that has the display ID and the :form2:display absolute client ID, which is the search expression for the findComponent method. An absolute client ID starts with the separator character of the naming container, which is : by default.

The <h:form>, <h:dataTable>, and composite JSF components, along with <p:tabView>, <p:accordionPanel>, <p:dataTable>, <p:dataGrid>, <p:dataList>, <p:carousel>, <p:galleria>, <p:ring>, <p:sheet>, and <p:subTable> are the components that implement the NamingContainer interface. The findComponent method, which is described at http://docs.oracle.com/javaee/7/api/javax/faces/component/UIComponent.html, is used by both JSF core implementation and PrimeFaces.

There's more…

JSF uses : (colon) as the separator for the NamingContainer interface. The client IDs that will be rendered in the source page will be of the kind id1:id2:id3. If needed, the configuration of the separator can be changed for the web application to something other than the colon with a context parameter in the web.xml file of the web application, as follows:

<context-param>
  <param-name>javax.faces.SEPARATOR_CHAR</param-name>
  <param-value>_</param-value>
</context-param>

It's also possible to escape the : character, if needed, in the CSS files with the \ character, as \:. The problem that might occur with the colon is that it's a reserved keyword for the CSS and JavaScript frameworks, like jQuery, so it might need to be escaped.

The PrimeFaces Cookbook Showcase application

This recipe is available in the demo web application on GitHub (https://github.com/ova2/primefaces-cookbook/tree/second-edition). Clone the project if you have not done it yet, explore the project structure, and build and deploy the WAR file on application servers compatible with Servlet 3.x, such as JBoss WildFly and Apache TomEE.

For the demos of this recipe, refer to the following:

• Basic Partial Page Rendering is available at http://localhost:8080/pf-cookbook/views/chapter1/basicPPR.jsf
• Updating Component in a Different Naming Container is available at http://localhost:8080/pf-cookbook/views/chapter1/componentInDifferentNamingContainer.jsf
• An example of Partial Processing is available at http://localhost:8080/pf-cookbook/views/chapter1/partialProcessing.jsf