Learn AJAX

Ajax Principles

noreply@blogger.com (Smrithi) — Mon, 28 Jan 2008 08:48:00 +0000

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.

How Http Communication Works

noreply@blogger.com (Smrithi) — Mon, 28 Jan 2008 07:08:00 +0000

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.

HTTP PRIMER

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:
<request-line>
<headers>
<blank>
[<request-body>]

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:
POST / 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
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
name=ajax%20book&publisher=smrithi

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:
<status-line>
<headers>
<blank line>
[<response-body>]

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

<html>
<head>
<title>Example Homepage</title>
</head>
<body>

</body>
</html>

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.

What Sets Ajax Apart - Difference between Ajax and other technologies

noreply@blogger.com (Smrithi) — Fri, 11 Jan 2008 04:54:00 +0000

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.

Why Ajax for Greater Design

noreply@blogger.com (Smrithi) — Thu, 10 Jan 2008 06:39:00 +0000

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;

document.body.appendChild(newScript);

}

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

<html>

<head>
<title>AJAX Tutorial: Example 1

</title>

</script>
<script language="JavaScript">

function doSomethingWithData(str){

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

}
</script>

</head>
<body>

<h1>AJAX Tutorial: Example 1

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

<br>

<p>

</div>

</p>

</body>

</html>

Now, the ajax code in ajax.js file

function loadScript(scriptURL){

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

newScript.src = scriptURL;

document.body.appendChild(newScript);}
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

break;

case 1: // Loading

break; case 2:

// Loaded

break; case 3: // Interactive

break;

case 4: // Done!

// Retrieve the data between the tags

doSomethingWithData(xmlReq.responseXML.getElementsByTagName('quote')[0].firstChild.data);

break;

default:

break;

}

}
// 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

<html>

<head>

</script>
<script language = "JavaScript">

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

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

}//-->

</script>
<title>AJAX Tutorial: Example 2

</title>

</head>

<body>

<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.

<br>

</div>

</p>

</body>

</html>

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

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

<root>

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

</root>

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

Ajaxifying a Web Application - Auto-population of Data

noreply@blogger.com (Smrithi) — Tue, 08 Jan 2008 04:19:00 +0000

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

<html>
<head>
<title>Customer Data Screen</title>
</head>
<body>
<h1>Corporate System</h1>
<h2>Enter Customer Data</h2>
<table>
<tr>
<th>Customer Name:</th>
<td><input type="text" name="name"/></td>
</tr>
<tr>
<th>Address:</th>
<td>
<input type="text" name="address"/>
</td>
</tr>
<tr><th
>City:</th><td>
<input type="text" name="city"/>
</td>
</tr>
<tr><th>State:</th><td>
<input type="text" name="state"/>
</td>
</tr>
<tr>
<th>Zip:</th><td>
<input type="text" name="zip"/>
</td></tr>
<tr>
<th></th>
<td><input type="Submit" value="Add Customer"/>
</td>
</tr>
</table>
</body>
</html>

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):

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

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:
<html>
<head>
<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];
}
}
</script>
</head>
<body>
<h1>Corporate System
</h1><h2>Enter Customer Data</h2><table><tr><th>Customer Name:</th><td><input type="text" name="name"/>
</td></tr><tr>
<th>Address:</th>
<td><input type="text" name="address"/>
</td></tr><tr><th>Zip:</th><td>
<input onblur="getZipData(this.value)"type="text" name="zip"/>
</td>
</tr>
<tr>
<th>City:
</th>
<td>
<input id="city" type="text" name="city"/>
</td>
</tr>
<tr>
<th>State:</th>
<td>
<input id="state" type="text" name="state"/>
</td>
</tr>
<tr>
<th>
</th>Report
<td><input type="Submit" value="Add Customer"/>
</td>
</tr>
</table>
</body>
</html>

Ajax Frameworks and Libraries - part1

noreply@blogger.com (Smrithi) — Fri, 04 Jan 2008 11:26:00 +0000

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
www.gerv.net/software/aul/
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
http://www.activewidgets.com/
Rich client JavaScript widgets; current flagship product is a rich grid widget.

3. Ajax JavaServer Faces Framework
Open Source (Apache)
http://smirnov.org.ru/en/ajax-jsf.html
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
http://ajaxtags.sourceforge.net/
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)
http://ajax.zervaas.com.au/
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
http://ajaxaspects.blogspot.com/
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
http://ajaxify.com/run/testAjaxCaller
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.

9.AjaxFaces
Open source(ASF)
http://myfaces.apache.org/
Apache's JavaServer Faces implementatio; currently experimenting with Ajax support.

10. BackBase
Commercial with community edition
http://www.backbase.com/
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
www.ripcord.co.nz/behaviour/
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.

12.Bindows
Commercial
http://www.bindows.net/
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.

13.BlueShoes
Commercial with free version
http://www.blueshoes.org/
Rich component suite, including a WYSIWYG text editor and spreadsheet widget.

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

15. CL-Ajax Richard Newman(2005)
Open Source
http://cliki.net/cl-ajax
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
www.daniel-zeiss.de/ComfortASP/
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
www.dynarch.com/projects/calendar
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)
http://cpaint.sourceforge.net/
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
http://dojotoolkit.org/
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
www.getahead.ltd.uk/dwr
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)
www.nextapp.com/products/echo2
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
http://fm.dept-z.com/
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

noreply@blogger.com (Smrithi) — Fri, 04 Jan 2008 08:19:00 +0000

23. FCKEditor
Open source
www.fckeditor.net
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
www.osflash.org/doku.php?id=flashjs
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)
http://goog-ajaxslt.sourceforge.net
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
www.javaguise.com
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)
www.twinhelix.com/JavaScript/htmlhttprequest/
Simple remote scripting wrapper. Uses XMLHttpRequest and IFrames as well for improved compatibility.

28. Interactive Website Framework
Open source
http://sourceforge.net/projects/iwf/
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
Commercial
www.jackbe.com/solutions/development.html
Ajax rich client widget suite; can be plugged into any middleware technology such as ASP, Java, .NET or PHP.

30. JPSpan
Open source
http://jpspan.sourceforge.net/wiki/doku.php
JPSpan passes JavaScript calls directly to PHP functions. Heavily unit-tested.

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

32. JSON
Open source; most implementations are LGPL
http://json-rpc.org/
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)
www.ashleyit.com/rs/jsrs/test.htm
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
www.whitefrost.com/servlet/connector?file=reference/2003/06/17/libXml-Request.html
LibXMLHttpRequest is a thin wrapper around XMLHttpRequest.

35. Mochikit
Open source
www.mochikit.com/
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
www.netwindows.org
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
Commercial
www.oddpost.com
JavaScript widget suite; includes fully functional rich e-mail client. Now part of Yahoo!.

38. OpenRico
Bill Scott, Darren James (2005)
Open source
http://openrico.org
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
http://pragmaticobjects.com/products.html
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
http://prototype.conio.net
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)
http://qooxdoo.sourceforge.net
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
www.ashleyit.com/rs/main.htm
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
www.rubyonrails.org
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)
http://twilightuniverse.com/2005/05/sack-of-ajax
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.

45. SAJAX
Open source
www.modernmethod.com/sajax
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
http://sarissa.sf.net
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
http://script.aculo.us
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.

48. SWATO
Open source
http://swato.dev.java.net
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
Commercial
www.technicalpursuit.com
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
http://tinymce.moxiecode.com/
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
http://trimpath.com/project/wiki/JavaScriptTemplates
JavaScript template engine for splicing together data and presentation on the browser.

52. Walter Zorn's DHTML Libraries
Open source
http://www.walterzorn.com/index.htm
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
www.themidnightcoders.com/weborb/aboutWeborb.htm
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
www.themidnightcoders.com/weborb/aboutWeborb.htm
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
www.cross-browser.com
Veteran DHTML library, providing cross-browser support for animation, styling, events and other common functionality.

56. XAJAX
J.Max Wilson
Open source
http://xajax.sf.net
XAJAX passes JavaScript calls directly to PHP functions. Use a JavaScript stub to call a PHP script.

57. x-Desktop
Open source
www.x-desktop.org/
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
http://xkr.us/code/JavaScript/XHConn
XHConn is a thin wrapper around XMLHttpRequest.

Introduction to Dojo Toolkit

noreply@blogger.com (Smrithi) — Fri, 04 Jan 2008 04:22:00 +0000

This post is geared towards people with some javascript knowledge, that might have used another ajax/js framework before, but now have a really pressing need to use some of the features found in dojo framework.So, what is it really?

Dojo is quite a lot of things. It has a staggering amount of widgets, to begin with; Dialogs, Panes, Menus, WYSIWYG editors, Buttons, Color pickers, Clocks, Layout Managers and a host of other things- just in the widgets department. Then there's the very handy encryption package, handy for hashing things coming to and from the server-side, the Drag-n-Drop package which works with nearly any element on the page, the essential Collections API with Java-like iterators and what not, and of course the powerful proper Ajax functionality with several bells and whistles of its own.
Apart from the sheer amount of functionality available in dojo, there are a few architectural differences compared to most other frameworks; Dojo uses namespaces. This means that dojo always includes the package names in an object reference. If I want use the very nice for-each loop function, for instance, I have to refer to is like this; "dojo.lang.forEach(listOfThings, myFunc);” instead of just "forEach(listOfThings, myFunc);".It seems to be a lot of trouble and waste a lot of space, but in reality it's not a big change and it increases readability when debugging or refactoring things later. Another example is that when you want to refer to a DOM element the "dojo way", you write "dojo.byId(el.id);" instead of prototypes inarguably more compact "$(el.id);" Another big change in philosophy between dojo and prototype is that prototype has a long and glorious history of changing basic javascript objects, such as adding useful new functions to the string object.This has resulted in collisions or erratic behavior when using other javascript libraries which want to change or assume a certain functionality of the very same function names. By using namespaces, dojo ensures that no collisions occur between itself and any other libraries on the same page.Getting the right stuff and copying the right files to your server You might think that using a javascript-based framework should be dead simple. In many cases it is, but due to de facto standards set up by many smaller frameworks (or libraries), some design choices in dojo requires reading some of the fine print. The most important thing to remember is that dojo is more that just the file dojo.js. It is not uncommon for people starting to use dojo to assume that the src/ directory really isn't needed, and probably is shipped only as a kind of open source service to the developer. However, when you download and unzip the "standard" dojo package (dojo 0.4.2-ajax), the dojo.js file is only the starting point, the kernel so to speak, of dojo. All real functionality exists - and exists only - in files under the src/ directory. Also, most widgets have a lot of template html files and images that they have to get at, so the short dance version of this point is; Copy everything.

Check the test to see how things are done The biggest problem the dojo community faces (IMHO) is the lack of a thorough API documentation and walk-through examples. True, there's a very useful (at least to the intermediate-level dojo hacker) API tool, and there are several good sites which give fairly up-to-date walk-throughs and examples in specific areas. But the really good bits can be found on the test directory which also ships with the standard package. If you go to http://download.dojotoolkit.org/release-0.4.2/dojo-0.4.2p1-widget you'll see two interesting directories; demo and tests. The reason I refer to the live URL at the dojo download site is that you might want to poke around at other (upcoming) versions. The demo directory contains a fair number of demos, which are neatly organized in the following sections; Demo Applications (Mail client, Text editor), Effects (Fades, Wipes, Slides, et.c.), Drag and Drop, Storage, RPC, Layout Widgets, Form Widgets and General Widgets (Buttons, Menus, Fisheye menus, Tooltips, et.c.). This is a good place to let your jaw drop a bit and get some inspiration. But the really good stuff is found under the tests directory. Here you will find unit tests for almost all widgets, layout containers, graphics, and lots of other things you'll find truly useful. The reason the tests are more useful is that they are short, focused and sometimes even (drumrolll, please) commented! My recommendation is to check out tests/widget for test_ModalFloatingPane, test_Dialog and test_Menu2_Node for some basic examples on how to use dojo widgets. Although dojo is an Ajax framework, much of the truly sterling functionality it offers has little if anything to do with client-sever communication - as you will find out.Before you do the fancy stuff you're surely shaking with barely controlled desire to do, it's a good idea to get a minimal "template-page" up and running. Of course, you could just grab one of the tests files and change things about, but how fun would that be? Here is a minimal html-page to start with, happily snarfed from one of the Dialog tests and shortened a bit;

<html>
<head>
<title>My first Dojo page</title>
<script type="text/javascript" src="dojo.js"></script>
<script type="text/javascript">
dojo.require("dojo.widget.*");
</script>
<script>
var dlg;
function getResults(evt)
{
var name = dojo.byId("inputname").value;
dojo.byId("namediv").innerHTML = "<b>"+name+"</b>";
}
function init(e)
{
dlg = dojo.widget.byId("DialogContent");
dojo.event.connect("hider", "onclick", "getResults");
}
dojo.addOnLoad(init);
</script>
</head>
<body>
<a href="javascript:dlg.show()">Show Dialog</a> <br><br>Name:<div id="namediv">None</div>
<div dojoType="dialog" id="DialogContent" bgColor="white" bgOpacity="0.5" toggle="fade" toggleDuration="250" closeNode="hider">
<h3>First Dialog</h3>
<form onsubmit="return false;">
<table>
<tr>
<td>Name:</td>
<td><input type="text" id="inputname"></td>
</tr>
<tr>
<td>Description:</td>
<td><input type="text"></td>
</tr>
<tr>
<td>Location:</td>
<td><input type="file"></td>
</tr>
<tr>
<td colspan="2" align="center">
<input type="button" id="hider" value="OK"></td>
</tr>
</table>
</form>
</div>
</body>
</html>

The first thing that happens here is that we load the file dojo.js, where among other things the dojo.require function is defined. Then we call that require function for the things we really need in our page. We could have just added a lot of script statements to get pretty much the same effect, but what's with the require loader is that we can use wildcards to load a whole package at a time, for instance dojo.widget.*. This OK when doing happy testing, but in production it's a good idea to only load what you need.
Note also that the package structure of dojo is the same as the file structure, and actually derives from it. This means that if you create subdirectories for your own dojo-derived widgets or whatever, you can use the loader for them as well.Then comes a script section where we define the variables and setup function to use in the page, which are page-specific. We could have taken these out and put them in a separate file, which we then could load use the standard script tag. As long as it's only a dozen lines or so, I actually prefer to have them in the html file, if the logic is tightly coupled (as in this case) to the nearby elements.There are two function, one obvious callback function, which reads the value of an input field, and copies that the value of another element on the page. The other function is a setup function which calls the first function when the form is closed. It does so using dojos own dojo.event.connect function, which is very powerful and requires an article in its own right, but for our purposes here it suffices to say that it hides any browser quirks, to make events simpler to work with.The rest of the page consists of two parts; a link which shows the dialog form, and the dialog form itself. Note the lazy javascript in the href of the anchor tag, which uses the variable defined earlier to show the dialog.The second part of the page shows the standard dojo way of declaring widgets, by adding a 'dojotype' tag inside the element, which defines the type of widget to be created for the element. Note also the tag 'closeNode', which defines which node controls calls to the hide() function of the dialog.When the link is clicked on the page, the dialog is shown, and when the "OK" button is clicked the dialog is hidden and the getResults() function is called.

EVOLVING PORTAL

noreply@blogger.com (Smrithi) — Thu, 03 Jan 2008 06:25:00 +0000

More and more companies have been adopting a portal-based intranet. Portals give users an easy gateway for obtaining large quantities of information on one page. This eliminates the need for the user to go to multiple locations to get the information they need. Online portals such as Yahoo! allows us to obtain news, weather, sports scores, mail, games and so much more on just one page. Another portal is Amazon’s A9.com search portal, which lets us do searches on multiple areas without going to separate pages. We can search for web pages, books, images and much more on one page. A9.com utilizes Ajax to display the information on the screen. This allows for a great user experience since the user does not have to sit and wait for page re-rendering when new search results are displayed.

THE EVOLVING PORTAL

Over the time, portals have evolved from simple sites that let us check our mail and do a search to elaborate setups that allow us to obtain a large amount of information in little effort. By comparison, in the past we had to check one site for news, another for comics, and another for a search and so on. Either we had tons of bookmarks for the sites that we checked daily or we just mentioned our routine of what addresses to type into the browser.

THE CLASSIC PORTAL

We are all accustomed to classic portals – we have been using them for years – and a lot of company intranets are using them to improve company performance by having everything in one place. The classic portal is one that allows a user to log into the system and have the content personalized to her tastes. For example, a company portal can have one setup for a salesperson and another setup for a computer programmer. Both of these employees may need to have a window to the company calendar, but they both may not need to see the sales figures or the bug report for the applications. By limiting what they can see, we increase company security and improve the employees performance since they do not have to search for information all over the company intranet.

Another example of a classic portal is Yahoo! When we log into Yahoo!, we can check mail, change the weather to fit our current location, change the look and so much more. As shown in the figure, Yahoo!’s portal is customized to the needs of the user.

Before incorporating Ajax, Yahoo! accomplished this by sending us to maintenance screens to alter the information. One example of the maintenance page allows us to select the city that we live in so that the weather forecast is for our area. Later they have enhanced the user experience even more by incorporating Ajax into the portal in the same way that Amazon did with the A9.com portal.

THE RICH USER INTERFACE PORTAL

With an Ajax portal, the rich user interface is more dynamic than a classic portal while positively impacting the user’s experience. We can add new content and change the way the content is displayed in a seamless manner. A great example of this seamless interaction is in Amazon’s A9.com search portal. Let’s look at how that works. In the following figure, a search has been performed for Eric Pascarello with only the web checkbox selected.

Now let’s narrow the search results. We know that we are looking for a book that Pascarello has written, so we click the Book checkbox. The Book Results page is inserted into the right-hand side of the page. The search results for Eric Pascarello’s books are displayed without posting the entire page back to the server to obtain them.
Another example of using Ajax to enhance the portal experience is in the configuration of the portal. Ajax allows the user interface to become part of the configuration-management tools by having the user click on objects in the window instead of going to another web-page to configure the setup. The user can dynamically resize and position the elements on the screen, thus customizing his portal to fit his needs exactly.

ALTERNATIVE TO AJAX

noreply@blogger.com (Smrithi) — Wed, 02 Jan 2008 05:42:00 +0000

By now, nearly everyone who works in web development has heard of the term Ajax, which is simply a term to describe client-server communication achieved without reloading the current page. Most articles on Ajax have focused on using XMLHttp as the means to achieving such communication, but Ajax techniques aren't limited to just XMLHttpRequest. There are several other methods to achieve what AJAX can give to the end-user.
Dynamic Script Loading
The first alternate Ajax technique is dynamic script loading. The concept is simple: create a new <script/> element and assign a JavaScript file to its src attribute to load JavaScript that isn't initially written into the page. The beginnings of this technique could be seen way back when Internet Explorer 4.0 and Netscape Navigator 4.0 ruled the web browser market. At that time, developers learned that they could use the document.write() method to write out a <script/> tag. The caveat was that this had to be done before the page was completely loaded. With the advent of the DOM, the concept could be taken to a completely new level.
The Technique
The basic technique behind dynamic script loading is easy, all you need to do is create a <script/> element using the DOM createElement() method and add it to the page:
var oScript = document.createElement("script");oScript.src = "/path/to/my.js";document.body.appendChild(oScript);
Downloading doesn't begin until the new <script/> element is actually added to the page, so it's important not to forget this step. (This is the opposite of dynamically creating an <img/> element, which automatically begins downloading once the src attribute is assigned.)
Once the download is complete, the browser interprets the JavaScript code contained within. Now the problem becomes a timing issue: how do you know when the code has finished being loaded and interpreted? Unlike the <img/> element, the <script/> element doesn't have an onload event handler, so you can't rely on the browser to tell you when the script is complete. Instead, you'll need to have a callback function that is the executed at the very end of the source file.
Example 1
Here's a simple example to illustrate dynamic script loading. The page in this example contains a single button which, when clicked, loads a string ("Hello world!") from an external JavaScript file. This string is passed to a callback function (named callback()), which displays it in an alert. The HTML for this page is as follows:

<html>
<head>
<title>Example 2</title>
<script type="text/javascript">//<![CDATA[
function makeRequest(sUrl, oParams) {
for (sName in oParams) {
if (sUrl.indexOf("?") > -1) {
sUrl += "&";
} else {
sUrl += "?";
}
sUrl += encodeURIComponent(sName) + "=" + encodeURIComponent(oParams[sName]);
}
var oScript = document.createElement("script");
oScript.src = sUrl;
document.body.appendChild(oScript);
}
function messageFromServer(sText) {
alert("Loaded from file: " + sText);
}
function getInfo() {
var oParams = {
"name": document.getElementById("txtInput").value, "callback": "messageFromServer"
};
makeRequest("example2js.php", oParams);
}
//]]>
</script>
</head>
<body>
<input type="text" id="txtInput" value="Nicholas" />
<input type="button" value="Get Info" onclick="getInfo()" />
</body>
</html>

The JavaScript file example1.js contains a single line:
callback("Hello world!");
When the button is clicked, the makeRequest() function is called, initiating the dynamic script loading. Since the newly loaded script is in context of the page, it can access and call the callback() function, which can do use the returned value as it pleases. This example works in any DOM-compliant browsers (Internet Explorer 5.0+, Safari, Firefox, and Opera 7.0.

More Complex Communication
Sometimes you'll want to load a static JavaScript file from the server, as in the previous example, but sometimes you'll want to return data based on some sort of information. This introduces a level of complexity to dynamic script loading beyond the previous example.
First, you need a way to pass data to the server. This can be accomplished by attaching query string arguments to the JavaScript file URL. Of course, JavaScript files can't access query string information about themselves, so you'll need to use some sort of server-side logic to handle the request and output the correct JavaScript. Here's a function to help with the process:
function makeRequest(sUrl, oParams)
{
for (sName in oParams) {
if (sUrl.indexOf("?") > -1) {
sUrl += "&"; } else { sUrl += "?";
}
sUrl += encodeURIComponent(sName) + "=" + encodeURIComponent(oParams[sName]); }
var oScript = document.createElement("script"); oScript.src = sUrl; document.body.appendChild(oScript);
}
This function expects to be passed a URL for a JavaScript file and an object containing query string arguments. The query string is constructed inside of the function by iterating over the properties of this object. Then, the familiar dynamic script loading technique is used. This function can be called as follows:

var oParams = { "param1": "value1", "param2": "value2"};
makeRequest("/path/to/myjs.php", oParams)

Next, you need a way to assign the callback function to be used. It's quite possible that you'll want to access the same information on different pages and in different ways. Forcing each page to have a callback function named "callback" isn't very good architectural design. Instead, it would be better to tell the JavaScript file the name of the callback function to use so that it can be dynamically inserted. The name of the function can be passed as another parameter for the query string:

var oParams = { "param1": "value1", "param2": "value2", "callback": "myCallbackFunc"};
makeRequest("/path/to/myjs.php", oParams);

The file creating the JavaScript then has to take the name of the callback function and output it into the code, as below:

var sMessage = "Hello world!";
(sMessage);

The first part of this file sets the content type to text/javascript so that the browser recognizes it as JavaScript (though many browsers don't check the content type of files loaded using <script/>) Next, a JavaScript variable called sMessage is defined as a string, "Hello world!". The last line outputs the name of the callback function that was passed through the query string, followed by parentheses enclosing sMessage, effectively making it a function call. If all works as planned, the last line becomes:
myCallbackFunc(sMessage);

Example 2
This example builds upon the previous one, but this time, you're going to send some additional information to the server and tell it which callback function to call. First, take a look at the PHP file that will be outputting the JavaScript:

var sMessage = "Hello, ";var sName = "
";
(sMessage + sName);

The JavaScript that will be output defines two variables, sMessage and sName; the former is filled with "Hello, ", the latter is assigned the value of the name parameter in the query string. Then, the name of the callback function is out, passing in the concatenation of sMessage and sName (combining server-side data with data passed from the client).
On the client side, the web page contains a textbox and a button:

html>
<head>
<title>Example 2</title>
<script type="text/javascript">//<![CDATA[
function makeRequest(sUrl, oParams) {
for (sName in oParams) {
if (sUrl.indexOf("?") > -1) {
sUrl += "&";
} else {
sUrl += "?";
}
sUrl += encodeURIComponent(sName) + "=" + encodeURIComponent(oParams[sName]);
}
var oScript = document.createElement("script");
oScript.src = sUrl;
document.body.appendChild(oScript);
}
function messageFromServer(sText) {
alert("Loaded from file: " + sText);
}
function getInfo() {
var oParams = {
"name": document.getElementById("txtInput").value, "callback": "messageFromServer"
};
makeRequest("example2js.php", oParams);
} //]]>
</script>
</head>
<body>
<input type="text" id="txtInput" value="Nicholas" />
<input type="button" value="Get Info" onclick="getInfo()" />
</body>
</html>

When the button is clicked, the getInfo() method is called, which loads an object with a name parameter (taken from the textbox) and a callback parameter. Then, the makeRequest() function is called, passing in these values. After the script has been loaded, the messageFromServer() function will be called, popping up a message displaying what was received from the server

Drawbacks
Though dynamic script loading is a quick and easy way to establish client-server communication, it does have some drawbacks. For one, there is no feedback once the communication is initiated. If, for example, the file you are accessing doesn't exist, there is no way for you to receive a 404 error from the server. Your site or application may sit, waiting, because the callback function was never called.
Also, you can't send a POST request using this technique, only a GET, which limits the amount of data that you can send. This could also be a security issue: make sure you don't send confidential information such as passwords using dynamic script loading, as this information can easily be picked up from the query string.

HISTORY OF AJAX

noreply@blogger.com (Smrithi) — Mon, 31 Dec 2007 09:31:00 +0000

Many a year ago, Jeff Rouyer won the Netscape DHTML competition with his flying dude interface and put DHTML on the map. The winning entry, apart from being 3D in design which up until that point had not been seen on the Web, also had something that was quite uncharacteristic of Web pages.
Most of what you see today on the web in terms of DHTML Widgets can be attributed to a small number of people with Jeff leading the way. Granted there has been a progression over the years, but things like scrollers, tooltips, drag and drop, event handling, dynamic clipping etc were pioneered by Jeff many years before they became popular. For example, the sliding doors technique used in CSS today was used around ten years ago with JavaScript by Jeff. In short the guy is the grand daddy of DHTML and everyone else pales in comparison. I kid you not!

One of the unusual features of Jeff’s Award winning site was than rather than have a user traverse across multiple Web pages which consumes resources by opening separate window instances, Jeff was loading content dynamically into an existing interface. In other words all the content was being loaded into an existing element and all other elements were not being changed or swapped. We are talking pre Internet Explorer 4 days here.

Internet Explorer 4 was released a little later to challenge Netscape's dominance on the web, but it did not have a similar method where content could be loaded directly into a layer element by using layer.load();

As the popularity of Internet Explorer 4 gained it became increasingly important to Jeff to maintain cross browser compatibility and initially created a series of document.write() in an external file to allow content to be imported into a pre-existing html file. Obviously this was resource intensive and he went on to improve this method for Internet Explorer 4 by created a little Java Applet to allow Internet Explorer 4 to pass external content into an existing element.

Not long after that, he thought of the idea of using an IFrame technique where content would be loaded into a hidden IFrame and then sucked back out and into a div element. This was the genesis of what today is known as Remote IFrame Scripting. Remember we are talking close to a decade ago which is a good indicator of how far ahead of the curve Jeff was at the time.

Enter Ajax

Recently Garret Smith of Adaptive Path made a good case for using Asynchronous JavaScript and XML and coined the acronym "AJAX" to represent the notion of Remote IFrame Scripting. It is similar to the Remote IFrame technique in that things are handled on the client side, but as we shall see differs in significant ways.

Ajax is more a natural progression from an existing set of techniques as opposed to being something completely brand new. Yet within that progression, things are markedly different than in previous years in a couple of key areas:

· It provides a mechanism to mix and match xml with xhtml.
· It significantly reduces having to continually fetch things from a server (remote IFrame scripting is reasonably comparable here).
· It overcomes some speed bottlenecks that traditional Web development has fallen prey too. In most instances an Ajax based site will load quicker than a comparable traditional Web site.
· When done well, it significantly reduces initial load times.

Before proceeding, it should be noted that Ajax isn't a panacea. It has some problems that it needs to overcome as it continues to mature. But it is a promising field to be involved within and as the years roll on, it probably will greatly affect the way we think about building Web pages and Web applications.

It also needs to be clear that Ajax isn't a technology as such but rather is a technique that combines well with other technologies and techniques. For example, xml, dhtml, css, xhtml. In fact, Ajax really is DHTML with the xmlhttprequest object thrown in. It is amazing to think how one object can change the whole playing field.

As things currently stand in the Ajax field, we almost have two extremes going on. At one end of the continuum we have developers building all sorts of complicated JavaScript tags that in most instances are unnecessary and are overkill. At the other end of the scale we have these little examples floating around the Web that demonstrate how to load xml into a document or do some Ajax form processing.

What is Ajax?

Ajax itself is a technique, but to use the technique effectively one must become familiar with the philosophy behind the technique. In other words, it is not just the use of the technique that is important, but rather developing a different mindset and approach to Web development that is central.

To date, I have mentioned the term Ajax a number of times but have not described the central object that makes Ajax, Ajax. At the heart of Ajax are the xmlhttprequest object and its Microsoft's activeX equivalent. It is this object that allows data to be transferred asynchronously. In case you are not clear what asynchronous means, it is the ability to handle processes independently from other processes. Synchronous which is the opposite of asynchronous, then means that processes are dependent upon other processes. To illustrate let us use a classical Web page scenario.

Assume we have page A and on this page we have a number of elements, including a couple of script and style tags. With synchronous data transfer the script tag needs to be parsed before the next element is parsed. In this way then the next element to be parsed by the browser is dependent upon the script tag being parsed first. Effectively we are creating a bottleneck of one connection between Web page and browser. Style tags and link elements in the head section of the document create the same bottleneck effect. They have to be parsed one at a time before other page elements can download.

Once they have been parsed then the elements in the body section can use concurrent connections to help speed up the download process. For example, most servers handle between 2 to 4 concurrent connections between web page and browser.

Consequently, this means that 2 to 4 images or other page elements can load concurrently. Yet before that process starts what is between the head tags have to be parsed first, which can considerably delay the loading of web pages. Most particularly if you are using multiple CSS and JavaScript tags. Nearly every Web page and blog on the internet uses this method. It isn't hard to see why this may be a problem in terms of increasing page load speeds.

Asynchronously loading methods differ from this scenario because the loading processes are handled independently of each other and to a significant degree overcomes the bottle of traditional Web page design. As will be demonstrated later, the whole gist of this technique is to use minimal JavaScript initially and then push all the head related tags, including the rest of the JavaScript, CSS etc tags through an xmlhttprequest object. This method uses multiple connections rather than the single one that most traditional Web pages use and consequently speeds things up considerably.

AJAX toolkits as on Dec 2007

noreply@blogger.com (Smrithi) — Mon, 31 Dec 2007 08:45:00 +0000

What is interesting about the Ajax market is that it’s more diversified in 2007 than it was in 2005 - the number of toolkits keep growing and jostling position in terms of usage. Right now there are 241 Ajax toolkits and related libraries listed in the survey. There were about three dozen in 2005 and 170 in 2006. The number of options is growing.
Prototype and Script.aculo.us are the only toolkits to maintain a lead over the past three years. However, over all there are no clear winners or losers as even the strongest incumbents (i.e., Prototype and Script.aculo.us) are starting too loose ground. Some frameworks initially popular have faded nearly completely out of the market (i.e., xajax and Rico ) while others have sprung out of nowhere to become leading tookits (i.e., jQuery and Ext JS).
What is astonishing is the nearly complete lack of commercial Ajax frameworks. Backbase has had a lot of success making a comeback after loosing some market share in 2006, but other commercial Ajax frameworks have not been so lucky.

AJAX FRAMEWORKS

noreply@blogger.com (Smrithi) — Mon, 31 Dec 2007 08:12:00 +0000

The best technology to build dynamic web pages is Ajax. JavaScript code embedded into the HTML page is used to send requests to the server. At the server side, some processing is required to handle them, find the info or store the data. To do that, we need for a specialized framework. The framework has always a JavaScript part, and sometimes a server side part in another scripting language. A lot of them exist in various programming languages, in all environments around, but we retain here only the most widely used.

Summary
Why a framework?
Features of an Ajax framework
JavaScript libraries
PHP frameworks
Java frameworks
.NET frameworks
ColdFusion frameworks
Ajax and XUL
Beyond Ajax

Why a framework?
Actually, this framework is the Ajax engine described by J. J. Garrett and intended to suppress waiting for the user when accessing the server. The framework provides classical, cross-browser functions to use the XMLHttpRequest object. But a framework may go beyond that, and allow you to build "rich web applications", applications with a graphical user interface and other features of desktop software that run through a browser, while exchanging data with a remote server.

Features of an Ajax framework
Any Ajax framework is able to communicate with the server, and thus, to read data or to send its data or commands. In the last case a server-side script is required. The frameworks often add components that make use of the asynchronous communication with the server. The classical examples are buttons, tabbed panels, grids, list-boxes and other such widgets. A more innovative example, the "boxes" are more and more often implemented, and Lightbox and Slimbox are two of them. There are image galleries that place them side by side on the screen and that are making use of Ajax to display them instantaneously.
Framework may be server-driven also, and in this case, component are created on the server with a scripting language such as PHP, and sent to the browser. Ajax is used to transmit user actions to the server part, and to handle the results.
The ability to work offline as it is offered by Google Gears, may be added to the Ajax framework as well.

JavaScript libraries
Many Ajax frameworks and libraries rely solely upon JavaScript and contain no server components and therefore server technology dependencies.Most of them use XML as data format, and sometime JSON, another textual format.A JavaScript library is loaded with just a tag, as this:

This tag includes the "prototype" library into the page and its function become usable by the browser, in this page. Such Ajax libraries and frameworks include:

Prototype - http://www.prototypejs.org is the base of several other frameworks including that of Yahoo. Its goal seems to be in reducing the size of Ajax Code.

Script Aculo – http://script.aculo.us
Add more features to prototype.

Rico. – http://openrico.org/rico/home.page
Based also on prototype, add special effects to HTML pages.

Jquery – http://jquery.com
JavaScript library with Ajax support. It is equivalent to Script Aculo and uses fewer resources.

Mootools. – http://mootools.netAnother toolkit as JQuery, includes graphical effects.

Dojo Toolkit. – http://dojotoolkit.org
Uses packages with a mechanism to load them together along with the page. It can build reusable components and widgets, a lot of them is provided on the site. It allows to manipulate the DOM more easily, and to make graphical effects.

Qooxdoo. – http://qooxdoo.org
Includes advanced cross-browser layout managers and an advanced build system for graphical user interfaces similar to that of desktop software. Widgets are provided with the function to use them from the keyboard or the mouse. Third parties provide PHP or Java code to process data with XMLHttpRequest.

Yahoo UI. – http://developer.yahoo.com/yui
Library from the Yahoo search engine. Includes CSS resources.

Anaa. - http://www.anaa.edu
A simple library for GET and POST with callbacks. Implements responseHTML, the A.E.P. extension.

PHP frameworks
On the server side, the programmer may use PHP functions to process requests from the browser. PHP allows us to deal with database, search data, build pages or parts of page and publish the page or return data to the XMLHttpRequest object. PHP 5 specifically, thanks to its SimpleXML class, is able to create XML files that may be returned to the object. But all these tasks require special functions to write... however the work is already done in some free open source frameworks.

AjaxAC. – http://ajax.zervaas.com.au
Small PHP library.

Xajax. – http://www.xajaxproject.org/
More sophisticated, is made of a JavaScript library and PHP classes, to help in using other PHP functions written by you. Uses only the XML format, on the server side.

Tiny Ajax. – http://www.metz.se/tinyajax/quickstart.php
A small PHP 5 class.

Java frameworks
Java is the programming language that is the more often used to build web services.A Java framework permit to use Java web services interactively with a web page. The more commonly used are:
DWR (Direct Web Remoting) – http://getahead.org/dwr
Allows using Java functions as if they are part of the browser, from HTML code, thanks to its interface. A JavaScript part is used to update the page and another to get data with servlets.The technique is in generating in real time Java code from JavaScript code, send it to the server and run it.
Google Web Toolkit – http://code.google.com/webtoolkit/
A toolbox to develop Java applications, that are then compiled into JavaScript code, and this code processes the HTML page through DOM methods.
Legacy Java software for the web now is moving to Ajax. JavaServer Faces now includes Ajax features. ThinWire takes a unique approach in that the application is written as if it was desktop software. All the logic executes on the server, the framework encapsulates the web rendering and communication layers.

.NET frameworks
Microsoft Ajax Library - http://www.asp.net/ajax
(Formerly ATLAS) is made of a client side part: Microsoft AJAX Library, and a server side part: ASP.NET 2.0 Ajax Extensions. But a component library is also provided with graphical widgets: ASP.NET Ajax Control Toolkit.

Ajax .NET Professional- http://www.ajaxpro.info/
"Serializes" (converts and stores) .NET data to the JSON format.

ColdFusion frameworks
Libraries include:
AjaxCFC. http://www.robgonda.com/blog/projects/ajaxcfc
An object oriented framework that provides developers seamless integration between JavaScript and ColdFusion, and built-in security and debugging functions.

CFAjax. – http://www.indiankey.com/cfajax
Implements Ajax in such a way that ColdFusion method calls on the server gets executed using JavaScript a la Ajax.

Ajax and XUL
Ajax makes use of the JavaScript programming language, and XUL embeds also JavaScript into XML to define the interaction with the graphical user interface. The two systems work on the Firefox browser. The first one allows communicating with the server from a remote web page, the second one display an interface either in a local computer or through the net, with the same browser.The main difference is in the use of Canvas (HTML tag) to extend Ajax and to extend XUL, XPCom and XBL.

ZK. – http://www.zkoss.org
Framework designed for allowing Ajax and XUL to communicate.

Beyond Ajax
Some current developments will reinforce again the importance of Ajax by providing standard for RIA (Rich Internet Applications), mainly HTML 5 qui extends HTML with Web applications features and Google Gears that allows a Web application to run offline.

Synchronous VS. Asynchronous Requests

noreply@blogger.com (Smrithi) — Mon, 17 Dec 2007 06:33:00 +0000

Central object that makes Ajax, Ajax is XMLHttpRequest object and its Microsoft’s ActiveX equivalent. It is this object that allows data to be transferred asynchronously. In case you are not clear what asynchronous means, it is the ability to handle processes independently from other processes. Synchronous which is the opposite of asynchronous, then means that processes are dependent upon other processes. To illustrate let us use a classical Web page scenario.

Assume we have page A and on this page we have a number of elements, including a couple of script and style tags. With synchronous data transfer the script tag needs to be parsed before the next element is parsed. In this way then the next element to be parsed by the browser is dependent upon the script tag being parsed first. Effectively we are creating a bottleneck of one connection between Web page and browser. Style tags and link elements in the head section of the document create the same bottleneck effect. They have to be parsed one at a time before other page elements can download.

Once they have been parsed then the elements in the body section can use concurrent connections to help speed up the download process. For example, most servers handle between 2 to 4 concurrent connections between web page and browser.

Consequently, this means that 2 to 4 images or other page elements can load concurrently. Yet before that process starts what is between the head tags have to be parsed first, which can considerably delay the loading of web pages. Most particularly if you are using multiple CSS and JavaScript tags. Nearly every Web page and blog on the internet uses this method. It isn't hard to see why this may be a problem in terms of increasing page load speeds.

Asynchronously loading methods differ from this scenario because the loading processes are handled independently of each other and to a significant degree overcomes the bottle of traditional Web page design. As the previous blog shows the example of Ajax, the whole gist of this technique is to use minimal JavaScript initially and then push all the head related tags, including the rest of the JavaScript, CSS etc tags through an XMLHttpRequest object. This method uses multiple connections rather than the single one that most traditional Web pages use and consequently speeds things up considerably.

Simple Example using AJAX-JSP

noreply@blogger.com (Smrithi) — Mon, 17 Dec 2007 03:32:00 +0000

The following code is a simple jsp page....save it as call.jsp

<%@page contentType="text/html"%>


<%@page pageEncoding="UTF-8"%>



<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>

<script language="javascript" src="ajax.js"></script> <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<title>JSP Page using AJAX
</title>
</head>
<body>
<a onclick="sendRequest('GET','index.jsp')"href="#">ServerDate Time:
</a>
<div id="ajax_res">Server Date Time will replace thistext.
</div>
</body>
</html>

Now lets see the actual ajax.js script as given below. This is the actual ajax related script which is used to make asynchronous request to the server using the XMLHttpRequest object.

ajax.js

function createRequestObject(){
var req; try {
// Firefox, Opera, Safari
req = new XMLHttpRequest();
} catch (e) {
// Internet Explorer
try {
//For IE 6
req = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
//For IE 5
req = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e) {
alert('Your browser is not IE 5 or higher, or Firefox or Safari or Opera');
}
}
}
return req;
}
//Make the XMLHttpRequest Object
var http = createRequestObject();
function sendRequest(method, url){
if(method == 'get' method == 'GET'){
http.open(method,url,true);
http.onreadystatechange = handleResponse;
http.send(null);
}
}
function handleResponse(){
if(http.readyState == 4 && http.status == 200){
var response = http.responseText;
if(response){
document.getElementById("ajax_res").innerHTML = response;
}
}
}

Now lets see the code for index.jsp where we get the date from the server

index.jsp

<%=new java.util.Date()%>

With these three files ie ajax.js, call.jsp and index.jsp, we can use Ajax with JSP.
Enjoy Ajaxing!!!

XMLHttpRequest - HEART OF AJAX

noreply@blogger.com (Smrithi) — Tue, 11 Dec 2007 06:17:00 +0000

Common XMLHttpRequest Object Properties

Common XMLHttpRequest Object Methods

XMLHttpRequest - what it actually does is simply provide a way for your client code (usually JavaScript in your Web page) to send an HTTP request.

Instead of a user request being made of the server via, for example, a normal HTTP POST or GET request, such as would be made by submitting a form or clicking a hyperlink, an Ajax script makes a request of a server by using the Javascript XMLHTTPRequest object.

Although this object may be unfamiliar to many, in fact it behaves like a fairly ordinary javascript object. As you may well know, when using a javascript image object we may dynamically change the URL of the image source without using a page refresh. XMLHTTPRequest retrieves information from the server in a similarly invisible manner.
There are two distinct methods for instantiating an XMLHttpRequest object. For Internet Explorer, an ActiveX object is used:
var req = new ActiveXObject(“Microsoft.XMLHTTP”);
For Mozilla and Safari, it's just a native object:\
var req = new XMLHttpRequest();
Instances of the XMLHttpRequest object in all supported environments share a concise, but powerful, list of methods and properties. Table 1 shows the methods supported by Safari 1.2, Mozilla, and Windows IE 5 or later.

Common XMLHttpRequest Object Methods have been shown above in the figure::

The open() and send() methods are the ones you'll likely use most. Two required parameters are the HTTP method you intend for the request and the URL for the connection. For the method parameter, use "GET" on operations that are primarily data retrieval requests; use "POST" on operations that send data to the server, especially if the length of the outgoing data is potentially greater than 512 bytes. The URL may be either a complete or relative URL.

An important optional third parameter is a Boolean value that controls whether the upcoming transaction should be handled asynchronously. The default behavior (true) is to act asynchronously, which means that script processing carries on immediately after the send() method is invoked, without waiting for a response. If you set this value to false, however, the script waits for the request to be sent and for a response to arrive from the server. While it might seem like a good idea to wait for a response before continuing processing, you run the risk of having your script hang if a network or server problem prevents completion of the transaction. It is safer to send asynchronously and design your code around the onreadystatechange event for the request object.

Common XMLHttpRequest Object Properties have been shown above

Once a request has been sent, scripts can look to several properties that all implementations have in common

The following generic function includes branched object creation, event handler assignment, and submission of a GET request. A single function argument is a string containing the desired URL. The function assumes that a global variable, req, receives the value returned from the object constructors. Using a global variable here allows the response values to be accessed freely inside other functions elsewhere on the page. Also assumed in this example is the existence of a processReqChange() function that will handle changes to the state of the request object.
var req;
function loadXMLDoc(url)
{
Req = false;
//check the browser’s compatibility with the XMLHttpRequest Object
if (window.XMLHttpRequest && !(window.ActiveXObject))
{
try
{
req = new XMLHttpRequest();
} catch(Exception e)
{
req = false;
}
}
elseif(window.ActiveXObject)
{
try
{
req = new ActiveXObject(“Msxml2.XMLHTTP”);
} catch(Exception e) {
try
{
req = new ActiveXObject(“Microsoft.XMLHTTP”);
}
Catch(Exception e){
req = false;
}
}
}
if(req)
{
req.onreadystatechange = processReqChange;
req.open (“GET”, url, true);
req.send (“”);
}
The following listing shows a skeletal onreadystatechange event handler function that allows processing of the response content only if all conditions are right.
function processReqChange()
{
//only if the request made is completed
if (req.readyState == 4)
{
if(req.status == 200)
{
//processing statements go here
}
else
{
alert (“problem with retrieving the XML data”+ req.statusText);
}
}
}

AJAX INTRO

noreply@blogger.com (Smrithi) — Mon, 10 Dec 2007 15:17:00 +0000

INTRODUCTION TO AJAX
Ajax (Asynchronous JavaScript + XML) is a recent name coined by Jesse James Garrett of Adaptive Path. Ajax isn’t a new technology. It’s a mix of several old technologies coming together in powerful new ways.

AJAX COMPARED TO CLUNKY WEB INTERFACES

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, talking to various legacy systems — and then returns an HTML page to the client.
This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.

Courtesy: http://www.adaptivepath.com/ideas/essays/archives/000385.php

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.
Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

When you write an application today, you have two basic choices:
Desktop applications
Web applications
Desktop applications are usually pretty fast (they're running on your computer; you're not waiting on an Internet connection), have great user interfaces (usually interacting with your operating system), and are incredibly dynamic. You can click, point, type, pull up menus and sub-menus, and cruise around, with almost no waiting around.
On the other hand, Web applications are usually up-to-the-second current and they provide services you could never get on your desktop (think about Amazon.com and eBay). However, with the power of the Web comes waiting -- waiting for a server to respond, waiting for a screen to refresh, and waiting for a request to come back and generate a new page.

Ajax attempts to bridge the gap between the functionality and interactivity of a desktop application and the always-updated Web application. You can use dynamic user interfaces and fancier controls like you'd find on a desktop application, but it's available to you on a Web application.

TECHNOLOGIES INVOLVED IN AJAX
CSS offers a way of defining reusable visual styles for web page elements. HTML is used to build Web forms and identify fields for use in the rest of your application.
JavaScript code is the core code running Ajax applications and it helps facilitate communication with server applications.
DHTML, or Dynamic HTML(combination of CSS,DOM and JavaScript), helps you update your forms dynamically. You'll use div, span, and other dynamic HTML elements to mark up your HTML.
DOM, the Document Object Model, will be used (through JavaScript code) to work with both the structure of your HTML and (in some cases) XML returned from the server.
XMLHttpRequest object is the heart of AJAX. It allows web programmers to retrieve data from the web server as a background activity. The data format is typically XML but it works well with any text-based data.