The AngularFaces way of doing AJAX

Most of the time AngularFaces replaces the original AJAX requests by its own, highly-optimized requests.

Synchronizing values between AngularJS scope and JSF beans works in both ways. The values of the input fields are transmitted back to the server, no matter whether you do a regular HTML request, a JSF AJAX request or the optimized AngularFaces request.

AngularFaces provides an advanced way of AJAX requests. Typically, they use a lot less network bandwidth, and they are faster than traditional JSF AJAX request. To activate an AngularFaces AJAX, you have to do two simple preparations:

Add an JSF AJAX button that includes a special update region: "angular". You've already seen this above:
```
<prime:commandButton value="save" update="angular" action="#{customer.save}" /> 
```

Add the id "angular" to the <h:body>.

<h:body ng-app="AngularFacesExamples" ng-controller="MyCtrl" id="angular">

Note that the id "angular" doesn't really mark an ordinary update region. It's a virtual id. If AngularFaces sees the id, it replaces the default update response generated by JSF by a highly-optimized response that updates only the scope values. However, there are also drawbacks to this approach. For instance, the <h:messages> tag isn't updated. Nor is <prime:growl>. I don't consider this a disadvantage: the idea of AngularFaces is to move such functionality to the client. Validation and presenting error messages in particular is Angular's job.

Beware of rendered="false"

It's a bad idea to use rendered="false" to hide a component in an AngularFaces page. AngularFaces uses optimized AJAX responses that update the variables of the scope, but nothing else. Hence, if you show or hide something on the server side using the rendered attribute, the HTML page is never updated. Better use ng-show, ng-hide or - as shown above - either style or styleClasses.

Under the hood

This is an example of an AngularFaces AJAX response:

<?xml version='1.0' encoding='UTF-8'?>
<partial-response id="j_id1">
  <changes>
  <eval><![CDATA[
     injectJSonIntoScope("calculatorBean",'{"result":107,
                        "randomNumberFromServer":50,
                        "number1":42,
                        "serverSideResult":107,
                        "number2":65}
                        ,window.jsfScope);
  ]]></eval>
  <update id="j_id1:javax.faces.ViewState:0"><![CDATA[...]]>
  </update>
  </changes>
    </partial-response>

Basically, the response consists of a single Javascript function that's send to the client. By contrast, a traditional JSF response replaces a part of the DOM tree. I've omitted a lot of the code in the following example, but you still can easily spot the difference:

<?xml version='1.0' encoding='UTF-8'?>
<partial-response id="j_id1">
  <changes>
  <update id="myForm">

<form id="myForm" name="myForm" method="post"
  action="/angularfaces-examples/manual/1_getting_started/primefaces.jsf"
  enctype="application/x-www-form-urlencoded">
  <input type="hidden" name="myForm" value="myForm" />

  <h2>Welcome to AngularFaces 2.0!</h2>
  Based firmly in the future...
  <div id="myForm:j_idt3" class="ui-panel ui-widget ui-widget-content ui-corner-all"
    data-widget="widget_myForm_j_idt3">
    <div id="myForm:j_idt3_header"
      class="ui-panel-titlebar ui-widget-header ui-helper-clearfix ui-corner-all">
      <span class="ui-panel-title">This is a JSF view enriched by an AngularJS bean</span>
    </div>
    <div id="myForm:j_idt3_content" class="ui-panel-content ui-widget-content">
      <table id="myForm:j_idt4" class="ui-panelgrid ui-widget" role="grid">
        <tbody>
          <tr class="ui-widget-content" role="row">
            <td role="gridcell" class="ui-panelgrid-cell">
              <label id="myForm:j_id8" class="ui-outputlabel ui-widget"
                for="myForm:j_idt5">
                <span class="ui-outputlabel-rfi">*</span>
              </label>
            </td>
            <td role="gridcell" class="ui-panelgrid-cell">
              <input id="myForm:j_idt5" name="myForm:j_idt5" type="number"
                value="42" min="7" ng-model="calculatorBean.number1" max="50"
                required=""
                class="ui-inputfield ui-inputtext ui-widget ui-state-default ui-corner-all"
                data-p-label="" data-p-con="javax.faces.Integer"
                data-p-maxvalue="50" data-p-minvalue="7" data-p-required="true"
                data-p-val="NotNull,Min,Max" />
              <script id="myForm:j_idt5_s" type="text/javascript">
                PrimeFaces.cw("InputText", "widget_myForm_j_idt5", {
                id : "myForm:j_idt5",
                widgetVar : "widget_myForm_j_idt5"
                });
              < /script>
            </td>
            <td role="gridcell" class="ui-panelgrid-cell">
              <angularfacesmessage af-for="myForm:j_idt5"></angularfacesmessage>
            </td>
          </tr>
          ...
        </tbody>
      </table>
      <div id="myForm:j_idt13" class="ui-messages ui-widget" aria-live="polite"
        data-summary="data-summary" data-severity="all,error">
        <div class="ui-messages-info ui-corner-all">
          <span class="ui-messages-info-icon"></span>
          <ul>
            <li>
              <span class="ui-messages-info-summary">Last calculation on the server side: 42+65=107</span>
            </li>
          </ul>
        </div>
      </div>
    </div>
  </div>
  <script id="myForm:j_idt3_s" type="text/javascript">
    PrimeFaces.cw("Panel", "widget_myForm_j_idt3", {
    id : "myForm:j_idt3",
    widgetVar : "widget_myForm_j_idt3"
    });
  < /script>
  ...
</form>
  </update>
  <update id="j_id1:javax.faces.ViewState:0"><![CDATA[...]]>
  </update>
  </changes>
</partial-response>

BTW: The fading effect is caused by the syntax highlighting tools I use, but it's funny how it makes the difference seem even more dramatic.