Automatic Ajax

Version 23 by Feras Nasser
on Oct 29, 2012 19:57.

<< Changes from 22 to 23

compared with

Current by Philip Breau
on Apr 10, 2013 10:33.

Key

These lines were removed. This word was removed.

These lines were added. This word was added.

View page history

There are 7 changes. View first change.

		h1. Definition

		Automatic Ajax is a mechanism in the ICEfaces framework that calculates precise/minimal page updates from one JSF lifecyle to the next, eliminating the need for standard JSF _<f:ajax>_ tags in the page.

		h1. Comparing Automatic Ajax with Standard JSF Ajax

		h2. JSF <f:ajax> Tag

		JSF 2 includes Ajax capabilities with the _<f:ajax>_ tag. _<f:ajax>_ adds client-side behavior to its parent component, enabling it to perform an Ajax submission, cause execution of the JSF lifecycle, and ultimately render new view content to be inserted in the page. The page designer controls what type of event causes the submit to occur, and defines what components participate in the execute phase and what components must render as a result of the execute phase. The following page snippet illustrates an input field causing an output field to update when the user modifies and tabs out of the input field.

		{code}
		<h:form>
		<h:panelGrid columns="1">
		<h:inputText id="myinput" value="#{myBean.value}">
		<f:ajax execute="@this" event="blur" render="myoutput"/>
		</h:inputText>
		<h:outputText id="myoutput" value="#{myBean.value}"/>
		</panelGrid>
		</h:form>
		{code}
		The sequence of events resulting in a page update based on this markup is illustrated below.
		!ICEfaces-2.0-JSF-Ajax.png\|align=center!

		# User interacts with the input field and tabs out of it.
		# _onBlur_ event causes _<f:ajax>_ tag to execute.
		# Ajax Request is generated back to application.
		# JSF lifecycle executes on the _inputText_ component only, updating the model.
		# JSF render phase runs on _outputText_ component only.
		# Response is generated with page update containing markup associated with _outputText_.
		# DOM update is applied to the _outputText_ text field in the DOM.

		The application of _<f:ajax>_ is simple in a trivial use case such as this, but as page complexity increases so does the complexity of defining appropriate _<f:ajax>_ tags, and if you get it wrong, your application can become ill behaved.
		!JSF-Ajax-Complex.png\|align=center!
		In the final analysis, it proves unreasonable to wire _<f:ajax>_ tags into a complex page to achieve optimal/minimal page updates. It becomes necessary to wire together broader regions of a page that may need updating based on some event, resulting in larger page updates than actually required.

		h2. Automatic Ajax with ICEfaces

		ICEfaces Automatic Ajax feature guarantees minimal page updates under any condition, and does not require the page developer to consider how, when or why page updates occur. The key to Automatic Ajax is the use of [Direct-to-DOM\|Direct-to-DOM Rendering] (D2D) rendering in the ICEfaces framework. D2D does just what it says, and writes the output of the JSF rendering phase into a server-side DOM that represents exactly what the client DOM needs be. Using a cached version of the DOM, the framework calculates precisely the set of DOM updates required to affect the changes in the page at the completion of any JSF lifecycle.

		While D2D handles the page updating aspect, it is still necessary to initiate the whole process through some UI event. ICEfaces provides the [Single Submit\|Single Submit] features, which causes a component to submit itself automatically when the user interacts with it. The result is that it behaves much the same as including:
		{code}
		<f:ajax execute="@this", render="@all"/>
		{code}
		but does not update the entire page, as the D2D mechanism intercepts the page update and calculates the precise, minimal set of updates required. The _<icecore:singleSubmit>_ tag can wrap any number of components and enable them for single submission.
		but does not update the entire page, as the D2D mechanism intercepts the page update and calculates the precise, minimal set of updates required. The _<icecore:singleSubmit>_ tag can be placed inside a form tag to enable the form input components for single submission.

		Returning now to our trivial example, the JSF markup in an ICEfaces page would look like:
		{code}
		<h:form>
		<icecore:singleSubmit>
		<icecore:singleSubmit/>
		<h:panelGrid columns="1">
		<h:inputText id="myinput" value="#{myBean.value}"/>
		<h:outputText id="myoutput" value="#{myBean.value}"/>
		</panelGrid>
		</icecore:singleSubmit>
		</h:form>
		{code}
		The sequence of events resulting in a page update based on this markup is illustrated below.

		!ICEfaces-2.0-Automatic-Ajax.png\|align=center!

		# User interacts with the input field and tabs out of it.
		# _onBlur_ event cause _singleSubmit_ to occur on _inputText_.
		# Ajax Request is generated from singleSubmit.
		# JSF lifecycle executes on the _inputText_ component only, and model is updated.
		# JSF render phase runs on entire component tree producing a server-side DOM.
		# DOM differences are calculated and page update to _outputText_ is generated in the response.
		# DOM update is applied to the _outputText_ text field in the DOM.

		The beauty of this solution is that regardless of how complex the page becomes, minimal additional markup is required to ensure it behaves properly. You only needs to define what components are enabled with _singleSubmit_, and the ICEfaces framework does the rest.

		***************************************************************************************************************************************************************************************************************************
		[!icefaces-services-wiki.png\|align=center!\|http://www.icesoft.org/java/services/icefaces-professional-services.jsf]

		{panel}
		_NEED ICEFACES EXPERTS FOR YOUR PROJECT? OUR TEAM CAN HELP:_

		_* Build Custom Components_
		_* Develop a Proof of Concept_
		_* Development Best Practices & Architectural Review_
		_* Performance Tuning & Optimization_

		_Visit [ICEfaces Services\|http://www.icesoft.org/java/services/icefaces-professional-services.jsf] to learn more._
		{panel}\\

		***************************************************************************************************************************************************************************************************************************

		h1. Optimizing Automatic Ajax

		Automatic Ajax optimizes development time, but there is a trade off at run time as it is necessary to render the entire page to produce the DOM for comparison. It is possible to optimize this rendering with _<f:ajax>_ tags that override the _render="@all"_ behavior used to _singleSubmit_ on a given component. Attaching a _<f:ajax>_ tag as a child of any component will override the _singleSubmit_ behavior of that component and allow the developer to specify a subset of the component tree that should render. The ICEfaces framework detects this partial rendering and performs D2D only on that specific subset of the component tree.

		Returning to our trivial example, the following markup will ensure that only the _outputText_ is rendered.

		{code}
		<h:form>
		<icecore:singleSubmit>
		<icecore:singleSubmit/>
		<h:panelGrid columns="1">
		<h:inputText id="myinput" value="#{myBean.value}">
		<f:ajax execute="@this" event="blur" render="myoutput"/>
		</h:inputText>
		<h:outputText id="myoutput" value="#{myBean.value}"/>
		</panelGrid>
		</icecore:singleSubmit>
		</h:form>
		{code}
		Of course, this sort of optimization is unnecessary in such a trivial example, but could prove useful in more complex pages. Most importantly, it is an optimization, not a necessity. Optimizations can be applied near the end of the development cycle, when the characteristics of the application are well understood, and proper behavior has been well established.