Namespace ajax

Usage:

jsf.ajax.addOnError(handleError);
// ...
var handleError = function handleError(data) {
  //...
}

Implementation Requirements:

This function must accept a reference to an existing JavaScript function. The JavaScript function reference must be added to a list of callbacks, making it possible to register more than one callback by invoking jsf.ajax.addOnError more than once. This function must throw an error if the callback argument is not a function.

Usage:

jsf.ajax.addOnEvent(statusUpdate);
  // ...
var statusUpdate = function statusUpdate(data) {
  // ...
}

Implementation Requirements:

This function must accept a reference to an existing JavaScript function. The JavaScript function reference must be added to a list of callbacks, making it possible to register more than one callback by invoking jsf.ajax.addOnEvent more than once. This function must throw an error if the callback argument is not a function.

Usage:

Example showing all optional arguments:

<commandButton id="button1" value="submit"
    onclick="jsf.ajax.request(this,event,
      {execute:'button1',render:'status',onevent: handleEvent,onerror: handleError});return false;"/>
</commandButton/>

Implementation Requirements:

This function must:

• Be used within the context of a form.

• Capture the element that triggered this Ajax request (from the source argument, also known as the source element.

• If the source element is null or undefined throw an error.

• If the source argument is not a string or DOM element object, throw an error.

• If the source argument is a string, find the DOM element for that string identifier.

• If the DOM element could not be determined, throw an error.

• If the onerror and onevent arguments are set, they must be functions, or throw an error.

• Determine the source element's form element.

• Get the form view state by calling jsf.getViewState passing the form element as the argument.

• Collect post data arguments for the Ajax request.

  • The following name/value pairs are required post data arguments:
    • javax.faces.ViewState - Contents of javax.faces.ViewState hidden field. This is included when jsf.getViewState is used.
    • javax.faces.partial.ajax - true
    • javax.faces.source - The identifier of the element that triggered this request.
    • javax.faces.ClientWindow - Call jsf.getClientWindow, passing the current form. If the return is non-null, it must be set as the value of this name/value pair, otherwise, a name/value pair for client window must not be sent.

• Collect optional post data arguments for the Ajax request.

  • Determine additional arguments (if any) from the options argument. If options.execute exists:
    • If the keyword @none is present, do not create and send the post data argument javax.faces.partial.execute.
    • If the keyword @all is present, create the post data argument with the name javax.faces.partial.execute and the value @all.
    • Otherwise, there are specific identifiers that need to be sent. Create the post data argument with the name javax.faces.partial.execute and the value as a space delimited string of client identifiers.
  • If options.execute does not exist, create the post data argument with the name javax.faces.partial.execute and the value as the identifier of the element that caused this request.
  • If options.render exists:
    • If the keyword @none is present, do not create and send the post data argument javax.faces.partial.render.
    • If the keyword @all is present, create the post data argument with the name javax.faces.partial.render and the value @all.
    • Otherwise, there are specific identifiers that need to be sent. Create the post data argument with the name javax.faces.partial.render and the value as a space delimited string of client identifiers.
  • If options.render does not exist do not create and send the post data argument javax.faces.partial.render.
  • If options.delay exists let it be the value delay, for this discussion. If options.delay does not exist, or is the literal string 'none', without the quotes, no delay is used. If less than delay milliseconds elapses between calls to request() only the most recent one is sent and all other requests are discarded.
  • If options.resetValues exists and its value is true, ensure a post data argument with the name javax.faces.partial.resetValues and the value true is sent in addition to the other post data arguments. This will cause UIViewRoot.resetValues() to be called, passing the value of the render attribute. Note: do not use any of the @ keywords such as @form or @this with this option because UIViewRoot.resetValues() does not descend into the children of the listed components.
  • Determine additional arguments (if any) from the event argument. The following name/value pairs may be used from the event object:
    • target - the ID of the element that triggered the event.
    • captured - the ID of the element that captured the event.
    • type - the type of event (ex: onkeypress)
    • alt - true if ALT key was pressed.
    • ctrl - true if CTRL key was pressed.
    • shift - true if SHIFT key was pressed.
    • meta - true if META key was pressed.
    • right - true if right mouse button was pressed.
    • left - true if left mouse button was pressed.
    • keycode - the key code.

• Encode the set of post data arguments.

• Join the encoded view state with the encoded set of post data arguments to form the query string that will be sent to the server.

• Create a request context object that will be used during error/event handling. The function must set the properties:

  • source (the source DOM element for this request)
  • onerror (the error handler for this request)
  • onevent (the event handler for this request)

• Send a begin event following the procedure as outlined in the Chapter 13 Sending Events section of the Java Server Faces spec.

• Set the request header with the name: Faces-Request and the value: partial/ajax.

• Determine the posting URL as follows: If the hidden field javax.faces.encodedURL is present in the submitting form, use its value as the posting URL. Otherwise, use the action property of the form element as the URL.

• Determine whether or not the submitting form is using multipart/form-data as its enctype attribute. If not, send the request as an asynchronous POST using the posting URL that was determined in the previous step. Otherwise, send the request using a multi-part capable transport layer, such as a hidden inline frame. Note that using a hidden inline frame does not use XMLHttpRequest, but the request must be sent with all the parameters that a JSF XMLHttpRequest would have been sent with. In this way, the server side processing of the request will be identical whether or the request is multipart or not.

  The begin, complete, and success events must be emulated when using the multipart transport. This allows any

listeners to behave uniformly regardless of the multipart or XMLHttpRequest nature of the transport.

Form serialization should occur just before the request is sent to minimize the amount of time between the creation of the serialized form data and the sending of the serialized form data (in the case of long requests in the queue). Before the request is sent it must be put into a queue to ensure requests are sent in the same order as when they were initiated. The request callback function must examine the queue and determine the next request to be sent. The behavior of the request callback function must be as follows:

• If the request completed successfully invoke jsf.ajax.response passing the request object.
• If the request did not complete successfully, notify the client.
• Regardless of the outcome of the request (success or error) every request in the queue must be handled. Examine the status of each request in the queue starting from the request that has been in the queue the longest. If the status of the request is complete (readyState 4), dequeue the request (remove it from the queue). If the request has not been sent (readyState 0), send the request. Requests that are taken off the queue and sent should not be put back on the queue.

Usage:

jsf.ajax.response(request, context);

Implementation Requirements:

This function must evaluate the markup returned in the request.responseXML object and perform the following action:

• If there is no XML response returned, signal an emptyResponse error. If the XML response does not follow the format as outlined in Appendix A of the Java Server Faces spec prose document signal a malformedError error. Refer to section Signaling Errors in Chapter 13 of the Java Server Faces spec prose document.
• If the response was successfully processed, send a success event as outlined in Chapter 13 Sending Events section of the Java Server Faces spec prose document.

Update Element Processing

The update element is used to update a single DOM element. The id attribute of the update element refers to the DOM element that will be updated. The contents of the CDATA section is the data that will be used when updating the contents of the DOM element as specified by the <update> element identifier.

• If an <update> element is found in the response with the identifier javax.faces.ViewRoot:

  <update id="javax.faces.ViewRoot">
      <![CDATA[...]]>
  </update>
  

  Update the entire DOM replacing the appropriate head and/or body sections with the content from the response.

• If an <update> element is found in the response with an identifier containing javax.faces.ViewState:

  <update id="<VIEW_ROOT_CONTAINER_CLIENT_ID><SEP>javax.faces.ViewState<SEP><UNIQUE_PER_VIEW_NUMBER>">
      <![CDATA[...]]>
  </update>
  

  locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response. <SEP>: is the currently configured UINamingContainer.getSeparatorChar(). <VIEW_ROOT_CONTAINER_CLIENT_ID> is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated. <UNIQUE_PER_VIEW_NUMBER> is a number that must be unique within this view, but must not be included in the view state. This requirement is simply to satisfy XML correctness in parity with what is done in the corresponding non-partial JSF view. Locate and update the javax.faces.ViewState value for all forms specified in the render target list.

• If an update element is found in the response with an identifier containing javax.faces.ClientWindow:

  <update id="<VIEW_ROOT_CONTAINER_CLIENT_ID><SEP>javax.faces.ClientWindow<SEP><UNIQUE_PER_VIEW_NUMBER>">
      <![CDATA[...]]>
  </update>
  

  locate and update the submitting form's javax.faces.ClientWindow value with the CDATA contents from the response. <SEP>: is the currently configured UINamingContainer.getSeparatorChar(). <VIEW_ROOT_CONTAINER_CLIENT_ID> is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated. <UNIQUE_PER_VIEW_NUMBER> is a number that must be unique within this view, but must not be included in the view state. This requirement is simply to satisfy XML correctness in parity with what is done in the corresponding non-partial JSF view. Locate and update the javax.faces.ClientWindow value for all forms specified in the render target list.

• If an update element is found in the response with the identifier javax.faces.ViewHead:

  <update id="javax.faces.ViewHead">
      <![CDATA[...]]>
  </update>
  

  update the document's head section with the CDATA contents from the response.

• If an update element is found in the response with the identifier javax.faces.ViewBody:

  <update id="javax.faces.ViewBody">
      <![CDATA[...]]>
  </update>
  

  update the document's body section with the CDATA contents from the response.

• For any other <update> element:

  <update id="update id">
      <![CDATA[...]]>
  </update>
  

  Find the DOM element with the identifier that matches the <update> element identifier, and replace its contents with the <update> element's CDATA contents.

Insert Element Processing

• If an <insert> element is found in the response with a nested <before> element:

  <insert>
      <before id="before id">
          <![CDATA[...]]>
      </before>
  </insert>
  

  • Extract this <before> element's CDATA contents from the response.
  • Find the DOM element whose identifier matches before id and insert the <before> element's CDATA content before the DOM element in the document.

• If an element is found in the response with a nested element:

  <insert>
      <after id="after id">
          <![CDATA[...]]>
      </after>
  </insert>
  

  • Extract this <after> element's CDATA contents from the response.
  • Find the DOM element whose identifier matches after id and insert the <after> element's CDATA content after the DOM element in the document.

Delete Element Processing

• If a <delete> element is found in the response:

  <delete id="delete id"/>
  

  Find the DOM element whose identifier matches delete id and remove it from the DOM.

Element Attribute Update Processing

• If an <attributes> element is found in the response:

  <attributes id="id of element with attribute">
      <attribute name="attribute name" value="attribute value">
       <!-- ... -->
  </attributes>
  

  • Find the DOM element that matches the <attributes> identifier.
  • For each nested <attribute> element in <attribute>, update the DOM element attribute value (whose name matches attribute name), with attribute value.

JavaScript Processing

• If an <eval> element is found in the response:

  <eval>
      <![CDATA[...JavaScript...]]>
  </eval>
  

  • Extract this <eval> element's CDATA contents from the response and execute it as if it were JavaScript code.

Redirect Processing

• If a <redirect> element is found in the response:

  <redirect url="redirect url"/>
  

  Cause a redirect to the url redirect url.

Error Processing

• If an <error> element is found in the response:

  <error>
      <error-name>..fully qualified class name string...<error-name>
      <error-message><![CDATA[...]]><error-message>
  </error>
  

  Extract this <error> element's error-name contents and the error-message contents. Signal a serverError passing the errorName and errorMessage. Refer to section Signaling Errors in Chapter 13 of the Java Server Faces spec prose document.

Extensions

• The <extensions> element provides a way for framework implementations to provide their own information.
• The implementation must check if <script> elements in the response can be automatically run, as some browsers support this feature and some do not. If they can not be run, then scripts should be extracted from the response and run separately.