AJAX events specifications are similar to the regular POST and GET events in most areas. The few differences are highlighted here, as well as some implementation implications.

Event Source

Like with non-AJAX based events, the event source is depicted with the identity of the event source and the event type, as shown below.

       form[categoryForm].element[source element].change

For standard event, the even type must be related to server event. For AJAX event, it is a client event type that must be specified.

       form[categoryForm].element[source element].onchange

Parameters

Like non-AJAX events, parameters passed to the event need to be specified. The point of note here is the need to be more explicit in specifying parameters. For example, because the form post involves all elements in the form, the parameters for such events need not be explicit. For component based framework, the component tree is represented on the server and client side, so the issue of parameters could be implicit.

As a default it is possible to pass the page view as parameters; however performance would be enhanced if a subset is passed. This is the case, especially when the AJAX interaction involves a small fraction of components on the page.

AJAX events specifications are similar to the regular POST and GET events in most areas. The few differences are highlighted here, as well as some implementation implications.

Event Source

Like with non-AJAX based events, the event source is depicted with the identity of the event source and the event type, as shown below.

       form[categoryForm].element[source element].change

For standard event, the even type must be related to server event. For AJAX event, it is a client event type that must be specified.

       form[categoryForm].element[source element].onchange

Parameters

Like non-AJAX events, parameters passed to the event need to be specified. The point of note here is the need to be more explicit in specifying parameters. For example, because the form post involves all elements in the form, the parameters for such events need not be explicit. For component based framework, the component tree is represented on the server and client side, so the issue of parameters could be implicit.

As a default it is possible to pass the page view as parameters; however performance would be enhanced if a subset is passed. This is the case, especially when the AJAX interaction involves a small fraction of components on the page.

Implementation

For the elements from the UICommand family and output links, it is necessary to select AJAX aware components when resolving the element type. This makes sense, since standard components would invoke a standard event rather than going through the AJAX mechanism. These alternatives are presented in the overview of the element descriptor.

For elements of other types, it suffices to employ an AJAX extender. Seam provides such extender, in a4j:support component. We illustrate the use of this component with a simple specification.

The specification is as follows.

The event source element would be represented in the element descriptor, only the AJAX event is captured above. The segment to be re-rendered must also be demarcated in the segment descriptor, with the link with the AJAX event (event-id).

These elements and segment are shown in the source content below.

<input type="text" id="in" />

<!--aws:segment id="result"?-->

	<h:outputText?id="result"?value="#{bean.countryName}"/>

<!--/aws:segment?-->

The implementation code is shown below.

<h:inputText id="in" value="#{bean.countryCode}">

????<a4j:support?event="onchange"?action="#{bean.refresh}" reRender="result"/>

</h:inputText>

<h:outputText?id="result"?value="#{bean.countryName}"/>

The segment to re-render is inline, without behavior, that has a single component within; therefore the re-rendering could target the single component.

AJAX Extender

The extender provided is a4j:support. The event descriptor mapping to the component attributes is provided in the table below.