Learn AJAX

Search the Web:


Monday, January 28, 2008

Ajax Principles

Michael Mahemoff a software developer and usability expert, identified several key principles of good Ajax applications that are worth repeating:

Minimal traffic: Ajax applications should send and receive as little information as possible to and from the server. In short, Ajax can minimize the amount of traffic between the client and the server. Making sure that your Ajax application doesn't send and receive unnecessary information adds to its robustness.

No surprises: Ajax applications typically introduce different user interaction models than traditional web applications. As opposed to the web standard of click-and-wait, some Ajax applications use other user interface paradigms such as drag-and-drop or double-clicking. No matter what user interaction model you choose, be consistent so that the user knows what to do next.

Established conventions: Don't waste time inventing new user interaction models that your users will be unfamiliar with. Borrow heavily from traditional web applications and desktop applications so there is a minimal learning curve.

No distractions: Avoid unnecessary and distracting page elements such as looping animations, and blinking page sections. Such gimmicks distract the user from what he or she is trying to accomplish.

Accessibility: Consider who your primary and secondary users will be and how they most likely will access your Ajax application. Don't program yourself into a corner so that an unexpected new audience will be completely locked out. Will your users be using older browsers or special software? Make sure you know ahead of time and plan for it.

Avoid entire page downloads: All server communication after the initial page download should be managed by the Ajax engine. Don't ruin the user experience by downloading small amounts of data in one place, but reloading the entire page in others.

User first: Design the Ajax application with the users in mind before anything else. Try to make the common use cases easy to accomplish and don't be caught up with how you're going to fit in advertising or cool effects.

The common thread in all these principles is usability. Ajax is, primarily, about enhancing the web experience for your users; the technology behind it is merely a means to that end. By adhering to the preceding principles, you can be reasonably assured that your Ajax application will be useful and usable.

Sunday, January 27, 2008

How Http Communication Works

The driving force behind Ajax is the interaction between the client (web browser) and the server. Previously, the understanding of this communication was limited to those who developed purely on the server-side using languages such as Perl and C. Newer technologies such as ASP.NET, PHP, and JSP encouraged more of a mix of client- and server-side techniques for software engineers interested in creating web applications, but they often lacked a full understanding of all client-side technologies (such as JavaScript). Now the pendulum has swung in the other direction, and client-side developers need to understand more about server-side technology in order to create Ajax solutions.


Central to a good grasp of Ajax techniques is hypertext transmission protocol (HTTP), the protocol to transmit web pages, images, and other types of files over the Internet to your web browser and back. Whenever you type a URL into the browser, an "http://" is prepended to the address, indicating that you will be using HTTP to access the information at the given location.

HTTP consists of two parts: a request and a response. When you type a URL in a web browser, the browser creates and sends a request on your behalf. This request contains the URL that you typed in as well as some information about the browser itself. The server receives this request and sends back a response. The response contains information about the request as well as the data located at the URL (if any). It's up to the browser to interpret the response and display the web page (or other resource).

HTTP Requests

The format of an HTTP request is as follows:

In an HTTP request, the first line must be a request line indicating the type of request, the resource to access, and the version of HTTP being used. Next, a section of headers indicate additional information that may be of use to the server. After the headers is a blank line, which can optionally be followed by additional data (called the body).

There are a large number of request types defined in HTTP, but the two of interest to Ajax developers are GET and POST. Anytime you type a URL in a web browser, the browser sends a GET request to the server for that URL, which basically tells the server to get the resource and send it back. Here's what a GET request for http://www.example.com/ might look like:

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

The first part of the request line specifies this as a GET request. The second part of that line is a forward slash (/), indicating that the request is for the root of the domain. The last part of the request line specifies to use HTTP version 1.1 (the alternative is 1.0). And where is the request sent? That's where the second line comes in.

The second line is the first header in the request, Host. The Host header indicates the target of the request. Combining Host with the forward slash from the first line tells the server that the request is for www.example.com/. (The Host header is a requirement of HTTP 1.1; the older version 1.0 didn't require it.) The third line contains the User-Agent header, which is accessible to both server- and client-side scripts and is the cornerstone of most browser-detection logic. This information is defined by the browser that you are using (in this example, Firefox 1.0.1) and is automatically sent on every request. The last line is the Connection header, which is typically set to Keep-Alive for browser operations (it can also be set to other values, but that's beyond the scope of this book). Note that there is a single blank line after this last header. Even though there is no request body, the blank line is required.

If you were to request a page under the http://www.example.com/ domain, such as http://www.example.com/books, the request would look like this:
GET /books/ HTTP/1.1
Host: http://www.example.com/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

Note that only the first line changed, and it contains only the part that comes after http://www.example.com/ in the URL.
Sending parameters for a GET request requires that the extra information be appended to the URL itself. The format looks like this:
URL ? name1=value1&name2=value2&..&nameN=valueN

This information, called a query string, is duplicated in the request line of the HTTP request, as follows:
GET /books/?name=ajax%20book HTTP/1.1
Host: http://www.example.com/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

Note that the text "ajax book" had to be encoded, replacing the space with %20, in order to send it as a parameter to the URL. This is called URL encoding and is used in many parts of HTTP. (JavaScript has built-in functions to handle URL encoding and decoding; these are discussed later in the chapter). The name-value pairs are separated with an ampersand. Most server-side technologies will decode the request body automatically and provide access to these values in some sort of logical manner. Of course, it is up to the server to decide what to do with this data.

The POST request, on the other hand, provides additional information to the server in the request body. Typically, when you fill out an online form and submit it, that data is being sent through a POST request.
Here's what a typical POST request looks like:
Host: http://www.example.com/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive

You should note a few differences between a POST request and a GET request. First, the request line begins with POST instead of GET, indicating the type of request. You'll notice that the Host and User-Agent headers are still there, along with two new ones. The Content-Type header indicates how the request body is encoded. Browsers always encode post data as application/x-www-form-urlencoded, which is the MIME type for simple URL encoding. The Content-Length header indicates the byte length of the request body. After the Connection header and the blank line is the request body. As with most browser POST requests, this is made up of simple name-value pairs, where name is Professional Ajax and publisher is Wiley. You may recognize that this format is the same as that of query string parameters on URLs.
As mentioned previously, there are other HTTP request types, but they follow the same basic format as GET and POST. The next step is to take a look at what the server sends back in response to an HTTP request.

HTTP Responses

The format of an HTTP response, which is very similar to that of a request, is as follows:
<blank line>

As you can see, the only real difference in a response is that the first line contains status information instead of request information. The status line tells you about the requested resource by providing a status code. Here's a sample HTTP response:

HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122

<title>Example Homepage</title>
<!-- body goes here -->

In this example, the status line gives an HTTP status code of 200 and a message of OK. The status line always contains the status code and the corresponding short message so that there isn't any confusion. The most common status codes are:

200 (OK): The resource was found and all is well.

304 (NOT MODIFIED): The resource has not been modified since the last request. This is used most often for browser cache mechanisms.

401 (UNAUTHORIZED): The client is not authorized to access the resource. Often, this will cause the browser to ask for a user name and password to log in to the server.

403 (FORBIDDEN): The client failed to gain authorization. This typically happens if you fail to log in with a correct user name and password after a 401.

404 (NOT FOUND): The resource does not exist at the given location.

Following the status line are some headers. Typically, the server will return a Date header indicating the date and time that the response was generated. (Servers typically also return some information about themselves, although this is not required.) The next two headers should look familiar as well, as they are the same Content-Type and Content-Length headers used in POST requests. In this case, the Content-Type header specifies the MIME type for HTML (text/html) with an encoding of ISO-8859-1 (which is standard for the United States English resources). The body of the response simply contains the HTML source of the requested resource (although it could also contain plain text or binary data for other types of resources). It is this data that the browser displays to the user.
Note that there is no indication as to the type of request that asked for this response; however, this is of no consequence to the server. It is up to the client to know what type of data should be sent back for each type of request and to decide how that data should be used.

Thursday, January 10, 2008

What Sets Ajax Apart - Difference between Ajax and other technologies

While CSS, DOM, aynchronous requests and Javascript are all necessary components of Ajax, it is quite possible to use all of them without doing Ajax.
In a classic web application when compared to its Ajax counterpart, the user workflow is defined by code on the server and the user moves from one page to another, punctuated by the reloading of the entire page. During these reloads, the user cannot continue with his work. In an Ajax application, the workflow is at least partly defined by the client application, and contact is made with the server in the background while the user gets on with his work.
In between these extremes are many shades of gray. A web application may deliver a series of discrete pages following the classic approach, in which each page cleverly uses CSS, DOM, JavaScript and asynchronous request objects to smooth out the user's interaction with the page, followed by an abrupt halt in productivity while the next page loads. A JavaScript application may present the user with page-like pop-up windows that behave like classic web-pages at certain points in the flow. The web browser is a flexible and forgiving environment and Ajax and non-Ajax functionality can be intermingled in the same application.
What sets Ajax apart is not the technologies that it employs but the interaction model that it enables through the use of those technologies. The web-based interaction model to which we are accustomed is not suited to sovereign applications and new possibilities begin to emerge as we break away from that interaction model.
There are atleast two levels at which Ajax can be used - and several positions between these as we let go of the classic page-based approach. The simplest strategy is to develop Ajax-based widgets that are largely self-contained and that can be added to a web page with a few imports and script statements. Stock tickers, interactive calendars, and chat windows might be typical of this sort of widget. Islands of application-like functionality are embedded into a document-like web page. Most of the Google's current forays into Ajax fit this model. The drop-down box of Google Suggest and the map widget in Google Maps are both interactive elements embedded into a page.
If we want to adopt Ajax more adventurously, we can turn this model inside out, developing a host application in which application-like and document-like fragments can reside. This approach is more analogous to a desktop application or even a window manager or desktop environment. Google's gmail fits this model, with individual messages rendering as documents within an interactive, application-like superstructure.
In some ways, learning the technologies is the easy part. The interesting challenge in developing with Ajax is in learning how to use them together. We are accustomed to thinking of web applications as storyboards, and we shunt the user from one page to another following a pre-determined script. With the application-like functionality in our web application, we can provide the user with a more fine-grained handle on the business domain, which can enable a more freee-form problem solving approach to his work.

Wednesday, January 9, 2008

Why Ajax for Greater Design

When it comes to web applications, AJAX offers two crucial advantages:

  • It is efficient: only a part of the web page that needs to be modified is being modified. With traditional server-side scripting you send the entire new page to the browser.
  • It is lightweight: only small amounts of data (in the XML form) are being exchanged through the Internet, making your web applications very fast.

How to retrieve static data dynamically

If your web page needs data that is already available (in a file) and does not need to be assembled, here is what to do:

  • Place the data in a .js file, and
  • Use the loadScript() function below to dynamically load and use the .js file you need

function loadScript(scriptURL){

var newScript = document.createElement("script");

newScript.src = scriptURL;



The loaded script runs immediately in the document context, allowing you to modify page elements as needed.

Lets see the example. First the html file. Save this as Example1.html


<title>AJAX Tutorial: Example 1


<script language="JavaScript" src="ajax.js">

<script language="JavaScript">

function doSomethingWithData(str){

document.getElementById('MyID').innerHTML = str;



<h1>AJAX Tutorial: Example 1

</h1> This example shows how to dynamically retrieve data from a JavaScript file.



<input type="button" value="Data file #1" onclick="loadScript('Data1.js')" />

<input type="button" value="Data file #2" onclick="loadScript('Data2.js')" />

<input type="button" value="Data file #3" onclick="loadScript('Data3.js')" />


<div id="MyID">&nbsp;





Now, the ajax code in ajax.js file

function loadScript(scriptURL){

var newScript = document.createElement("script");

newScript.src = scriptURL;

function loadData(URL){

// Create the XML request

xmlReq = null; if(window.XMLHttpRequest)

xmlReq = new XMLHttpRequest();

else if(window.ActiveXObject) xmlReq = new ActiveXObject("Microsoft.XMLHTTP");

if(xmlReq==null) return;

// Failed to create the request
// Anonymous function to handle changed request states

xmlReq.onreadystatechange = function() {

switch(xmlReq.readyState) {

case 0: // Uninitialized


case 1: // Loading

break; case 2:

// Loaded

break; case 3: // Interactive


case 4: // Done!

// Retrieve the data between the tags






// Make the request

xmlReq.open ('GET', URL, true); xmlReq.send (null);


In the Example1.html, we create 3 buttons to get the information in that file on to the page, those files are named as Data1.js, Data2.js and Data3.js

Save the below code as Data1.js

doSomethingWithData("Life is like a dogsled team. If you ain't the lead dog, the scenery never changes (Lewis Grizzard)");

Save the below code as Data2.js

doSomethingWithData("Anyone can steer the ship when the sea is calm (Publilius Syrus)");

Save the below code as Data3.js

doSomethingWithData("A leader is a dealer in hope (Napoleon Bonaparte)");

To better understand what is going on, let us examine all the files being used.

The function loadScript is stored in the ajax.js file. As soon as the specified script file has been loaded, the script inside it is executed. The Data1.js file is used to store or compute the data requested. For simplicity, it only has one line of code:

When the first button is clicked, it calls loadScript('Data1.js'), whick loads and then executes the script in Data1.js. This script passes the data as a parameter to doSomethingWithData (str), which is defined in Example1.htm. In our example, the data is displayed by modifying the div "MyID".

How to retrieve dynamic data dynamically

In many cases, the data is not readily available and must be assembled by a process or from a database. JavaScript does this by using XMLHttpRequest and receiving the content of an xml file in response.
The xml file can then be processed and used to modify various elements on your web page, which is illustrated in Example 2.

Save the html file as Example2.html



<script type="text/javascript" src="ajax.js">

<script language = "JavaScript">

<!--// Function to call with the data retrieved from the XML file function doSomethingWithData(datastr) {

document.getElementById('MyID').innerHTML = datastr;


<title>AJAX Tutorial: Example 2




<h1>AJAX Tutorial: Example 2

</h1> This example shows how to dynamically retrieve data from an XML file. Note: have your web server running on your local machine, or place the example on the web.



<input type="button" value="Load data.xml" onclick="loadData('data.xml');" />

<p> <div id="MyID">&nbsp;





Next take the actual xml file and save it as data.xml

<?xml version="1.0" encoding="utf-8"?>


<quote>Silence is foolish if we are wise, but wise if we are foolish (Charles Colton)</quote>


Data.xml is a simple data file. In this example, we are retrieving the data between the <quote> .. </quote> tags. The ajax.js file contains the loadData (URL) function, which does most of the work. The loadData() function creates and then makes the XML request. For the sake of simplicity, the URL is the xml file itself (our Data.xml). In more complex applications, the URL could be a call to a php, asp, or some other process responsible for assembling and returning the XML data. Observe the line xmlReq.onreadystatechange = function(): it defines an anonymous function (in this case) to call whenever the readyState shanges. Here we only process the case when the script is fully loaded: responseXML holds the received XML file, and xmlReq.responseXML.getElementsByTagName retrieves the part of it we are interested in. Similar to our previous example, this script passes the data as a parameter to doSomethingWithData(str), which is defined in Example2.html.

When the button is clicked, it makes a loadData() call to the process that will return the data in the form of an XML file. When the file is fully loaded, doSomethingWithData() is called to process the results. The whole process is illustrated below:
Web browser -> AJAX application -> XML request -> server-side process -> XML file generated -> XML file sent back to XML request -> onreadystatechange received by AJAX application -> data from XML file retrieved/processed -> web browser displays results

Monday, January 7, 2008

Ajaxifying a Web Application - Auto-population of Data

To start, let’s take a look at the source code for a form that a customer must fill in:

<title>Customer Data Screen</title>
<h1>Corporate System</h1>
<h2>Enter Customer Data</h2>
<th>Customer Name:</th>
<td><input type="text" name="name"/></td>
<input type="text" name="address"/>
<input type="text" name="city"/>
<input type="text" name="state"/>
<input type="text" name="zip"/>
<td><input type="Submit" value="Add Customer"/>

We want to add behavior so that when the user enters a value in the Zip field, we’ll send the ZIP code to the server, receive a response containing the city and state that correspond to the ZIP, and populate the City and State fields with those values.

Preparing the HTML
The first step towards this end will be to add an event handler to the event handler Zip <input> tag. Event Handlers in HTML allow you to execute script code in the web page when certain user interactivity or browser tasks occur. Secondly, we’ll have to add id= attributes to the City and State <input> elements. Our revised <input> elements look like this (with the surrounding table rows shown for context):

<th>Zip:</th><td><input onblur="getZipData(this.value)"type="text" name="zip"/>
<th>City:</th><td><input id="city" type="text" name="city"/>
<th>State:</th><td><input id="state" type="text" name="state"/>

The event handler is registered via the onblur= attribute, which in this case specifies that the script function named getZipData( ) will be invoked when the focus leaves this element. The parameter passed to this function, this.value, specifies that the value property of the <input> element will be passed; the this is a reference to the element on which the event handler has been registered.
We’ve also changed the ordering of the table rows; now the Zip input comes first. While this new layout is atypical for American addresses, it reflects a more natural flow for the ajaxified version of the screen, since entering the ZIP code will auto-populate the other two fields beneath it.

Communicating with the Server

We’re now done with the first half of our task: wiring the HTML to a script that will perform our Ajax behavior. Now we need to tackle the slightly trickier second bit: writing the script. The key to Ajax is a JavaScript object called XMLHttpRequest, the engine that can send HTTP requests, receive responses, and parse them as XML. Let’s create our getZipData( ) function, which will create an instance of XMLHttpRequest and use it to send the ZIP code to the server. Remember, this function will be invoked whenever the Zip input loses focus; that is, whenever the user enters the field and then leaves it, either with the mouse, the tab key, or some other mechanism. Here’s what it looks like so far:

1 <script type="text/JavaScript">
2 var xhr;
3 function getZipData(zipCode) {
4 xhr = new XMLHttpRequest();
5 xhr.open("GET", "/getCityStateFromZip.request?" + zipCode);
6 xhr.send(null);
7 }
8 </script>

On line 4, we create our XMLHttpRequest instance. On the next line, we configure it using the open( ) function; the first parameter indicates the HTTP method to use for the request, and the second indicates the URL we’ll be requesting. Finally, we invoke the send( ) function, which predictably enough sends the request.

Parsing the Response

Now that we’ve demonstrated how to send a request to the server, we need to add some code that will process the response that the server sends back. We’ll do that by creating a function processZipData( ):

1 function processZipData() {
2 var data = xhr.responseText;
3 var cityState = data.split(',');
4 document.getElementById("city").value = cityState[0];
5 document.getElementById("state").value = cityState[1];
6 }

The first few lines of this function are fairly intuitive; we retrieve the data sent back fromthe server—the city and state, formatted as “City,State”— and split the string into a two-element string array, so that we can access the city and state values separately. Lines 4 and 5 demonstrate why we gave id attributes to the City and State input elements earlier. Web browsers model every web page they display as an XML document (regardless of how ugly the page’s HTML markup is). In JavaScript code, we can access this XML document using the document variable. document has a handy getElementById( ) function that can return a reference to any XML element based on the id attribute. Once we have a reference to the element, we can manipulate it. In this case, we set the value attribute of the elements to the city and state values returned by the server.

Tying It All Together

We’ve created two JavaScript functions: getZipData( ), which sends a request to the server, and processZipData( ), which processes the response. However, we haven’t yet connected them. As our code currently stands, processZipData will never be invoked.

You might think that we should invoke processZipData( ) as we do on line 5 of the following example.

1 function getZipData(zipCode) {
2 xhr = new XMLHttpRequest();
3 xhr.open("GET", "/getCityStateFromZip.request?" + zipCode);
4 xhr.send(null);
5 processZipData();
6 }

Unfortunately, this just doesn’t work. The “A” in Ajax stands for asynchronous, and asynchronous behavior is exactly what we’re seeing here.

It turns out that when we invoke the send function on line 4, the invocation returns immediately and the XMLHttpRequest will make the request and receive the response on a separate thread. Thus, if we were to try to process the response from the server on the following line, we
couldn’t—we would not yet have received the response.
The solution is to register a callback handler—a function that will be callback handler
invoked when the XMLHttpRequest has received the response from the server. Line 3 in the following example demonstrates how to register processZipData as a callback handler:
1 function getZipData(zipCode) {
2 xhr = new XMLHttpRequest();
3 xhr.onreadystatechange=processZipData;
4 xhr.open("GET", "/getCityStateFromZip.request?" + zipCode);
5 xhr.send(null);
6 }

By simply passing the name of the function to the onreadystatechange( ) method, we are almost ready. Why is the method named onreadystatechange( ) and not, say, onresponsereceived( )? It turns out that XMLHttpRequest calls back into the function we registered multiple times as
it sends the request and receives the response, each time indicating that it has made progress. We’re only interested in parsing the data once the entire process has finished, so we need to check the current status of the XMLHttpRequest before we attempt to get the response data
in processZipData( ):
1 function processZipData() {
2 if (xhr.readyState == 4) {
3 var data = xhr.responseText;
4 var cityState = data.split(',');
5 document.getElementById("city").value = cityState[0];
6 document.getElementById("state").value = cityState[1];
7 }
8 }

XMLHttpRequest provides a readyState property that indicates its current status; a state of “4” indicates that the response has been received.

That’s it, we’re done. Let’s take a look at the entire web page source code to see how all these pieces fit together:
<title>Customer Data Screen</title>
<script type="text/javascript">var xhr;
function getZipData(zipCode) {
xhr = new XMLHttpRequest();
//<label id="code.xhr"/>
xhr.onreadystatechange=processZipData;xhr.open"GET","/getCityStateFromZip.request?" + zipCode);xhr.send(null);
function processZipData() {
if (xhr.readyState == 4) {
var data = xhr.responseText;
var cityState = data.split(',');
document.getElementById("city").value = cityState[0];
document.getElementById("state").value = cityState[1];
<h1>Corporate System
</h1><h2>Enter Customer Data</h2><table><tr><th>Customer Name:</th><td><input type="text" name="name"/>
<td><input type="text" name="address"/>
<input onblur="getZipData(this.value)"type="text" name="zip"/>
<input id="city" type="text" name="city"/>
<input id="state" type="text" name="state"/>
<td><input type="Submit" value="Add Customer"/>

Friday, January 4, 2008

Ajax Frameworks and Libraries - part1

The year 2006 has seen a rapid proliferation of Ajax and Javascript frameworks, from small cross-browser wrapper utilities to complete end-to-end client and server solutions. In this post, let's take a snapshot of some of the current range of offerings. These frameworks which will be described include the functionalities they had in that particular year and might have changed a lot as the time passed.

1. AccessKey Underlining Library
Open source
Adds accesskey underlining to pages without requiring tags in the source. Tag items with the accesskey attribute and javascript will create the appropriate underlining tags in the DOM.

2. ActiveWidgets
Commercial with free download
Rich client JavaScript widgets; current flagship product is a rich grid widget.

3. Ajax JavaServer Faces Framework
Open Source (Apache)
The Ajax-JSF framework is designed to allow simple conversion of any existing JavaServer Faces application to Ajax functionality. Most of the existing components can be used as is or simply converted to Ajax support. Proposal to MyFaces project. Minimal differences from JSF specifications.
4. Ajax JSP Tag Library
Open Source
The Ajax JSP Tag Library is a set of JSP tags that simplify the use of Asynhronous Javascript and XML(Ajax) technology is JavaServer Pages. This tag library eases development by not forcing J2EE developers to write the necessary JavaScript to implement an Ajax-capable web form. Autocomplete retrieves a list of values that matches the string enteres in a text form field as the user types. Callout displays a callout or popout balloon, anchored to an HTML element with an onclick event. Select populates a second select field based on a selection within a drop-down field. Toggle switches a hidden form field between true and false and at the same time switches an image between 2 sources. Update Field updates one or more form field values based on the response to text entered in another field.

5. Ajax.NET
Michael Schwarz(2005)
Unspecified, free to use http://weblogs.asp.net/mschwarz/
Ajax.NET is a library enabling various kinds of access from JavaScript to server-side .NET. Can pass calls from JavaScript into .NET methods and back out to Java-Script callbacks. Can access session data from JavaScript. Caches results. No source code change needed on server-side; mark methods to expose with an attribute. Provides full class support for return values on client-side JavaScript, including DataTable, DataSet, DataView, Arrays and Collections.

6. AjaxAC
Open source(Apache2.0)
AjaxAC encapsulates the entire application in a single PHP class. All application code is self-contained in a single class (plus any additional JavaScript libraries). The calling PHP file/HTML page is very clean. You simply create the application class, then reference the application JavaScript and attach any required HTML elements to the application. No messy JavaScript code clogging up the calling HTML code; all events are dynamically attached. Easy to integrate with the templating engine, and hook into existing PHP classes or MySQL database for returning data from sub-requests. Extensible widget structure lets you easily create further JavaScript objects.

7. AjaxAspects
Free to use with source
AjaxAspects is an engine that uses JavaScript proxies to call server-side Web Service methods. Standard SOAP and WSDL is reused for the communication between client and server. Simple types and XML objects are supported as parameters and return values. Supports caching and quueing of actions.

8.AjaxCaller Michael Mahemoff(2005)
Open Source
AjaxCaller is a basic thread-safe wrapper around XMLHttpRequest mainly for Ajax newcomers; still raw alpha and under development and is only packaged with the AjaxPatterns live search demos for now. Follows REST principles.

Open source(ASF)
Apache's JavaServer Faces implementatio; currently experimenting with Ajax support.

10. BackBase
Commercial with community edition
BackBase is a comprehensive browser-side framework with support for rich browser functionality as well as .NET and Java integration. BackBase provides Rich Internet Application(RIA) software that radically improves the usability and effectiveness of online applications and increases developer productivity. With BackBase you can build web applications with a richer and more responsive user interface. BackBase provides separation of presentation from logic through a custom XHTML namespace.

11. Behaviour
Ben Nolan(2005)
Open Source
Behaviour works by using CSS selectors to add JavaScript code to DOM elements. You can create a hash of CSS selectors and functions that take an element, and add JavaScript event handlers such as onclick. You then register these rules against a page and compare them against their matching DOM elements and the JavaScript code is added. The code is designed in a way that you can treat these rule files just like stylesheets so that all the page using them needs is an include. Behaviour's goal is to remove the heavy use of onclick attributes and script nodes from pages so they aren't messing up content. It works well and help make your JavaScript more reusable since it's more centralized.

Bindows is a software development kit that generates highly interactive Internet applications with richness that rivals modern desktop applications using the strong combination of DHTML, JavaScript, CSS and XML. Bindows applications require no downloads and no installation on the user's side; only a browser is required(no Java, Flash or ActiveX is used). Bindows provides a range of widgets as well as native XML,SOAP and XML-RPC support.

Commercial with free version
Rich component suite, including a WYSIWYG text editor and spreadsheet widget.

14. CakePHP
Open source
A comprehensive port of Ruby on Rails to PHP, including top-notch support for Ajax.

15. CL-Ajax Richard Newman(2005)
Open Source
CL-Ajax directs JavaScript calls directly into server-side Lisp functions. Generates JavaScript stub with arguments. Can call back to JavaScript functions or DOM objects. May be integrated into SAJAX.

16. ComfortASP.NET
Pre-release commercial with free download
ComfortASP.NET is an approach that lets developers rely on pure ASP.NET programming while offering Ajax-like features. ComfortASP.NET uses Ajax (DHTML, Javascript, XMLHTTP) to implement these features, but the web developer only implements pure server-side ASP.NET.

17. Coolest DHTML Calendar
Open Source with commercial support
Configurable Javascript calendar widget; can be wired up to form fields as a drop-down or pop-up and styled using CSS.

18. CPAINT (Cross Platform Asynchronous Interface Toolkit)
Open Source(GPL and LGPL)
CPAINT is a true Ajax implementation and JSRS (Javascript Remote Scripting) implementation that supports both PHP and ASP/VBScript. CPAINT provides you the code required to implement Ajax and JSRS on the back-end, while the returned data is manipulated, formatted and displayed on the front-end in JavaScript. This allows you to build web applications that can provide near real-time feedback to the user.

19. Dojo Alex Russell (2004)
Open Source
Dojo provides several libraries for use with Ajax, including widgets, an event model, and messaging using XMLHttpRequest and other techniques. Aims to support JavaScript in a range of settings, including SVG and Netscape's Java based Rhino engine, as well as in the web browser.

20. DWR (Direct Web Remoting)
Open source
Direct Web Remoting is a framework for calling Java methods directly from Java Script code. Like SAJAX, it can pass calls from JavaScript into Java methods and back out to Javascript callbacks. It can be used with any web framework - such as Struts or Tapestry - following a Spring-like KISS/POJO/orthogonality philosophy. Direct Web Remoting is due to be incorporated into the next release of the Open Symphony WebWorks framework.

21. Echo 2
Open source (MPL or GPL)
Echo 2 allows you to code Ajax apps in pure Java. Automatically generates HTML and Javascript, and co-ordinates messages between the browser and the server. Offers messaging in XML. The developer can handwrite custom Javascript components if desired.

22. f(m)
Open Source
The f(m) project is an ECMAScript Base Class Library, based on the .NET Framework, that was written to serve as the foundation for a new breed of browser-based web applications.

Ajax Frameworks and Libraries- Part2

23. FCKEditor
Open source
Rich WYSIWYG editor widget; can be swapped in for an HTML text area in one line of javascript code, allowing easy integration with existing web applications, CMS, wikis and so forth. Very similar functionality to TinyMCE.

24. Flash JavaScript Integration Kit
Open source
The Flash JavaScript Integration Kit allows for the integration of JavaScript and Flash content. Enables JavaScript to invoke ActionScript functions and vice versa. All major data types can be passed between the two environments.

25. Google AjaxSLT
Open source license (BSD)
AjaxSLT is offered by the innovative search solutions company that refers to itself as "Google". Google AjaxSLT is a javascript framework for performing XSLT transformations as well as XPath queries. Builds on Google Map work.

26. Guise
Commercial with free downloads
Java-based server side component model(similar in some ways to JSF, but simpler). Currently integrates Ajax functionality for greater responsiveness.

27. HTMLHttpRequest
Angus Turnbull (2005)
Open source(LGPL)
Simple remote scripting wrapper. Uses XMLHttpRequest and IFrames as well for improved compatibility.

28. Interactive Website Framework
Open source
Interactive Website Framework is a project whose aim is to support the various aspects of Ajax infrastructure in the browser. Describes itself as a framework for creating highly interactive websites using Javascript, CSS, XML and HTML. Includes a custom XML parser for highly readable Javascript. Contains essentially all the plumbing for making Ajax-based websites, as well as other common scripts. Provides a thread safe XMLHttpRequest implementation and a wrapper around the DOM making for more readable code.

29. Jackbe
Ajax rich client widget suite; can be plugged into any middleware technology such as ASP, Java, .NET or PHP.

30. JPSpan
Open source
JPSpan passes JavaScript calls directly to PHP functions. Heavily unit-tested.

31. jsolait
Open source (LGPL)
Set of open source Javascript libraries, including cryptography, serialization and deserialization, XML-RPC and JSON-RPC.

32. JSON
Open source; most implementations are LGPL
JSON is a "fat free XML alternative" and JSON-RPC is a remote procedure prototcol, akin to XML-RPC, with strong support for JavaScript clients. Implementations exist for several server-side languages and platforms, including Java, Python, Ruby and Perl.

33. JSRS (JavaScript Remote Scripting)
Brent Ashley (2000)
JSRS routes calls directly from JavaScript into your server-side language and back out again. Known browsers: IE 4+, Netscape 4.x, Netscape 6.x, Mozilla, Opera 7 and Galeon. Server-side support: ASP, ColdFusion, PerlCGI, PHP, Python and JSP(servlet).

34. LibXMLHttpRequest
Stephen W.Coate
Source available, protected by copyright
LibXMLHttpRequest is a thin wrapper around XMLHttpRequest.

35. Mochikit
Open source
Mochikit is a set of libraries whose highlights include logging, visual effects, asynchronous task management, string and date/time formatting and a "painless" DOM manipulation API that makes heavy use of JavaScript's built-in Array objects and JSON-like notation to represent the DOM.

36. netWindows
Open source
Complete DHTML desktop/windowing environment inside the browser. Code is purely standards-based, with no browser hacks. Contains a "signals and slots" messaging implementation, modeled after Trolltech's Qt widgets and the Small-talk language; also available as a standalone library.

37. Oddpost
JavaScript widget suite; includes fully functional rich e-mail client. Now part of Yahoo!.

38. OpenRico
Bill Scott, Darren James (2005)
Open source
A multipurpose framework with support for Ajax. Covers user interface issues such as animations, separation of content from logic through behaviours, drag and drop, and some prebuilt widgets, notably a data grid. Sponsored by Sabre Airline Solutions; has seen real world use. Built on top of Prototype.

39. Pragmatic Objects
Open source
Pragmatic Objects WebControls is a set of JSP tag libraries designed as reusable controls or components to enrich Java-based web applications. As opposed to rich but fat web applications, a thin client web application, at the end of the day, consists of nothing but a series of HTML pages, containing JavaScript and CSS codes that are rendered by the browsers. Current offerings consist of an "outlook bar", a tree widget and a control panel.

40. Prototype
Sam Stephenson
Open source
Prototype is a Javascript framework designed for RIA development. It includes a solid Ajax library and a toolkit to simplify use. Prototype is the JavaScript engine for Ruby on Rails, Rico, and Scriptaculous, among others. Prototype's JavaScript code is generated from Ruby, but the generated Javascript may be deployed in non-Ruby environments.

41. Qooxdoo
Open source (LGPL)
This is an Ajax user interface library with a large range of prebuilt components and a well-thought-out design. Includes widgets, layout managers, and portable PNG transparency. Also provides development support such as timers for profiling and debugger support.

42. RSLite
Brent Ashley
A simple component released as part of Brent Ashley's more comprehensive Remote Scripting work.

43. Ruby on Rails
David Heinemeier Hansson (2004)
Open source
Ruby on Rails is a general framework with strong Ajax support. Rails was still in its early days when the Ajax hype began, so Ajax may become increasingly core to the Rails framework. Generated most if not all of the JavaScript for widgets and animation in the browser. Support for calling server-side. Scheduling support. Current darling of the fashionable web development crowd, Ruby on Rails eschews the complex, over-designed, cover-all-bases strategy in favour of a straightforward, getting-the-job-done approach, with the help of a good deal of code generation. Has won over many Java developers for that reason.

44. Sack
Open source (modified MIT/X11)
Sack is a thin wrapper around XMLHttpRequest. The caller can specify a callback function or a callback DOM object. With a callback DOM, the response text is pushed directly into the DOM.

Open source
SAJAX routes calls directly from JavaScript into your server-side language and back out again. So, for example, calling a JavaScript method x_calculateBudget() will go to the server and call a Java calculateBudget() method, then return the value in Javascript to x_calculateBudget_cb(). Facilities mapping from a JavaScript stub function to a back-end operation. Capable of stubbing calls to numerous server-side platforms: ASP, ColdFusion, Io, Lua, Perl, PHP, Python and Ruby.

46. Sarissa
Open source
Sarissa is a JavaScript API that encapsulates XML functionality in browser-independent calls. Supports a variety of XML technologies, including XPath queries, XSLT and serialization of JavaScript objects to XML, in a browser-neutral way.

47. Scriptaculous
Thomas Fuchs
Open source
Scriptaculous is a well-documented visual effects library built in Javascript on top of Prototype. It includes demos, sample applications, and a drag-drop library.

Open source
SWATO (Shift Web Application TO...) is a set of reusable and well-integrated Java/Javascript libraries that give you an easier way to shift the interaction of your web apps through the Ajax way. The server-side Java library can be easily deployed in all Servlet 2.3+ compatible containers. The client-side JavaScript library can be worked in various browsers, as long as XMLHttpRequest is supported. SWATO uses JSON to marshal the data of your POJOs on the server side, so that you can access the remote data in any Javascript environment(HTML, XUL, SVG) easily by either hard-coding or by integrating with mature JavaScript libraries. Comes with several reusable components(Auto-complete Textbox, Live Form, Live List, etc.) that help you develop your web apps rapidly.

49. Tibet
Tibet aims to provide a highly portable and comprehensive Javascript API, so that a great amount of client-side code is possible. Pitches itself as "Enterprise Ajax" supports web service standards such as SOAP and XML-RPC, with pre-built support for some popular web services such as Google, Amazon, and Jabber instant messaging. Includes an IDE written in JavaScript using the Tibet toolkit.

50. Tiny MCE
Open source with commercial backing and some proprietary plug-ins
Rich WYSIWYG editor widget; can be swapped in for an HTML textarea in one line of JavaScript code, allowing easy integration with existing web-applications, CMS, wikis, etc. Very similar functionality to FCKEditor.

51. TrimPath Templates
Open source
JavaScript template engine for splicing together data and presentation on the browser.

52. Walter Zorn's DHTML Libraries
Open source
DHTML libraries for drag and drop support, and for vector graphics drawing of lines and curves by using DIV elements as pixels.

53. WebORB for .NET
Commercial with free edition
WebORB for .NET is a platform for developing Ajax and Flash-based rich client application and connecting them with .NET objects and XML web services.

54. WebORB for Java
Commercial with community/free edition
WebORB for java is a platform for developing Ajax and Flash-based rich client application and connecting them with Java objects and XML web services. Includes a client-side library called Rich Client System. (www.themidnightcoders.com/rcs/index.htm). The Rich Client System provides a simple one-line API to bind to and invoke any method on any Java object, XML web service or Enterprise JavaBean. Provides a special API for handling database query results; the server code can return DataSets or DataTables, and the client presents it as a special RecordSet JavaScript object. The object provides a way to retrieve column names as well as row data.

55. x
Mike Foster
open source
Veteran DHTML library, providing cross-browser support for animation, styling, events and other common functionality.

J.Max Wilson
Open source
XAJAX passes JavaScript calls directly to PHP functions. Use a JavaScript stub to call a PHP script.

57. x-Desktop
Open source
This project comprises a library for developing thin client application front-ends using a browser. It helps developers to create GUI application interfaces for Internet, intranet and extranet applications. x-Desktop features include the fact that it is browser bsed and that no plug-ins are required. It supports all operating systems that provide a DOM 2/JavaScript capable browser; offers a simple well-documented object interface; and provides a customizable desktop and window skins.

58. XHConn
Brad Fults
XHConn is a thin wrapper around XMLHttpRequest.