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.

1) The specification for an element that triggers a partial page refresh would look 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 an association with the AJAX event (event-id).

As far as the element implementation is concerned, the association of a segment with an ajax call-type would imply that the target segment that would be implemented as an update panel, instead of a simple inline panel. Associated with this update panel is a trigger entry that links the event source with the update panel.

For more discussion on this consult the event-id attribute of the segment descriptor.

2) For an element involved in server service invocation through AJAX, the specification could appear as shown below.

This is different from the segment or partial update scheme, in which methods in the backing bean could be invoked to update or refresh data that would be presented over again. In this scheme a service that is independent of the page would be consulted. The client script that made the request could obtain return data and reflect them on the event-source or other elements.

It has been discussed elsewhere and would be repeated here, that the client or scripting activities although captured in the source content and tested through the mock-up process, does not feature in the descriptors. The descriptors capture mapping for server side activities.

ASP.NET encapsulates all the scripting required to make the AJAX call and process its response. On platforms that use framework like DOJO, Prototype or JQuery, the prototyping could be done along with the mock-up process and would reside in the source content. It is easy to stub the call with request from local file system, to retrieve mock partial pages, JASON or XML data. The final implementation would now involve replacing the server calls with the stubs.

The breakdown of development allowed by using separate AJAX/JavaScript framework is not available for ASP.NET, because of the encapsulation provided by ASP.NET.

The best approach is to provide the specification and implementation for the basic function, and consider the AJAX enhancement separately. Although, the scripting aspects of the JAX call would not be captured, the portion of the specification that is captured could be very useful.

The entries are now analyzed below.

Call-Type

What marks an event as an AJAX event is the call-type “ajax”. For ASP.NET, the handler usually involves web service call, in which case, the call-type is also marked as “ws”. The service path and method would be reflected as the handler.

Event Source

The source of the event plus event type is entered; for ajax type, the event must be a client type event.

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

Parameters

The parameters used vary with the different AJAX Extenders and Components. It could also be implicit. For instance, for cascading drop down AJAX functionality, the selected item for the parent control becomes the filter parameter for the child control.

As such, the parameter would depend on the selection of the extender, and might be implicit based on the association with controls. In most cases, this attribute need not to be specified.

Implementation

For component base frameworks, the options for AJAX implementation is either to use AJAX aware components, or else attach AJAX extenders to standard components. The majority of the implementation for ASP.NET is based on AJAX extenders.

AJAX Extender

Although the main class is AjaxControlToolkit.ExtenderControlBase, the main property provided is the TargetControlID. This is the identifier for the control that extender is assisting. The translation from the event descriptor attributes to the common AJAX extender attributes is shown in the table below,

As mentioned above, the base extender offers only one useful attribute, which is the target control to attach the extender to. The other attributes must be analyzed on case by case basis. This, as mentioned earlier, should understandable since the AJAX extender is actually a cover for JavaScript based activities, as well as the AJAX call. For instance there are the following extenders that do not have anything to do with AJAX calls.

• AlwaysVisibleControl
• Calendar
• ColorPicker
• ConfirmButton
• ModalPopup

Whereas there are also the common AJAX features implementations.

• AutoComplete
• CascadingDropDown
• ComboBox

Because of the non-uniformity of the attributes for these extenders, the recommendation is to complete the elements specifications with the three extender attributes shown in the table above, as applicable. The implementation could them proceed with the basic functionalities, without the AJAX aspects. The AJAX functionality implementation could follow, using the information captured in the descriptor, while filling in the additional details needed.

Example specification is shown as follows:

Example implementation of the specification shown above is as follows:

<ajaxToolkit:AutoCompleteExtender ID="myTextBoxExtender" runat="server"
MinimumPrefixLength="1" ServiceMethod="GetCompletionList"
ServicePath="~/AutoComplete.asmx"
TargetControlID="myTextBox" />
 

The particular extender uses all the specification attributed shown above, without need for supplemental entries. As mentioned earlier, there would be need for additional entries for some extenders