First, take this last bit of overview before see into code.

Make sure to clear on this idea of the Web 2.0. When anybody hears the term Web 2.0, one asks; "What's Web 1.0?" Although web 1.0 is rarely heard, it is meant to refer to the traditional Web where we have a very distinct request and response model. For example, go to Amazon.com and click a button or enter a search term. A request is made to a server and then a response comes back to your browser. That request has a lot more than just a list of books and titles, though; it's actually another complete HTML page. As a result, you probably get some flashing or flickering as your Web browser's screen is redrawn with this new HTML page. In fact, you can clearly see the request and response, done by each new page you see.

The Web 2.0 dispenses with this very visible back-and-forth (to a large degree). As an example, visit a site like Gmail or newer Yahoo (links to both of these Web 2.0, Ajax-powered sites are in Resources). On Google Maps, for example, one can drag the map around and zoom in and zoom out with very little redrawing. Of course, requests and responses do go on here, but all behind the scenes. As a user, the experience is much more pleasant and feels a lot like a desktop application. This new feel and paradigm that is observed when someone refers to Web 2.0.

What care should care? how to make these new interactions possible? Obviously, we've still got to make requests and field responses, but it's the redrawing of the HTML for every request/response interaction that gives the perception of a slow, clunky Web interface. So clearly you need an approach that allows you to make requests and receive responses that include only the data you need, rather than an entire HTML page as well. The only time you want to get a whole new HTML page is when ... well ... when you want the user to see a new page.

But most interactions add details or change body text or overlay data on the existing pages. In all of these cases, Ajax and a Web 2.0 approach make it possible to send and receive data without updating an entire HTML page. And to any frequent Web surfer, this ability will makes application feel faster, more responsive, and bring them back over and over again.

Introducing XMLHttpRequest

To make all this flash and wonder actually happen, need to become clear and familiar with a JavaScript object called XMLHttpRequest. This little object; which has actually been around in several browsers for quite a while. This is key to Web 2.0; Ajax, and pretty much everything else you learn about in this column for the next several months. To give a really quick overview, here are just a few of the methods and properties frequently used on this object:

1. open(): Sets up a new request to a server.


2. send(): Sends a request to a server.


3. abort(): Terminates the current request.


4. readyState: Provides the current HTML ready state.


5. responseText: The text that the server sends back to respond to a request.

Don't worry about understanding all these; each of these methods and properties will be discussed in detail in future. What should be done with this stuff; though, its a good idea of what to do with XMLHttpRequest. Notice that each of these methods and properties relate to sending a request and dealing with a response. In fact, if you saw every method and property of XMLHttpRequest, they would all relate to that very simple request/response model.

So clearly, one won't learn about an amazing new GUI object or some sort of approach to create user interaction; we will work with simple requests and simple responses. It may not sound exciting; but careful usage of this object could change an application interaction method.

The simplicity of new

First, we need to create a new variable and assign it to an instance of the XMLHttpRequest object. That's pretty simple in JavaScript; we just use the new keyword with the object name, like you see in Listing below.

Listing.. Create a new XMLHttpRequest object

So we have created a variable in JavaScript with var, give it a name (like "request"), and then assign it to a new instance of XMLHttpRequest.

At that point, it is ready to be used with above functions.

Error handling

With out error handling in life, several problems could occour. A slightly better approach is to create this object and have it fail if something goes wrong. For example, many older browsers (believe it or not, people are still using old versions of Netscape Navigator) don't support XMLHttpRequest and one need to let those users know that something has gone wrong. Listing below shows how you may create this object so if something fails, it throws out a JavaScript Message (alert).

Listing.. Create XMLHttpRequest with some error-handling abilities

Make sure to understand each of these steps:

1. Create a new variable called request and assign it a false value. we'll use false as a condition that means the XMLHttpRequest object hasn't been created yet.


2. In a try/catch block;
   
   
   
   • Try and create the XMLHttpRequest object.
   
   
   • If that fails catch(failed) block, ensure that request is still set to false.
   
   


3. Check and see if request is still false (if things are going okay, it won't be).


4. If there was a problem (and request is false), use a JavaScript alert to tell users there was a problem.

This is pretty simple; it takes longer to read and write about than it does to actually understand for most JavaScript and Web developers. Now we've got an error-proof piece of code that creates an XMLHttpRequest object and even intimates if something goes wrong.

Dealing with Microsoft Browsers

If same above code is run on Microsoft browser(Internet Explorer), message will be displayed saying "Error initializing XMLHttpRequest!".
Clearly, something isn't working; Internet Explorer is hardly an out-of-date browser and about 70 percent of the world uses Internet Explorer one needs a different approach to deal with Microsoft's browsers.

It turns out that Microsoft supports Ajax, but calls its version of XMLHttpRequest something different.

In fact, it calls it several different things.

For a newer version of Internet Explorer,
Msxml2.XMLHTTP object needs to be used.

Some older versions of Internet Explorer use Microsoft.XMLHTTP; both these objects needs to be supported.

Listing.. Adding support for Microsoft browsers

In above code all the required possibilities are checked well. So that if any error occours with creation of XMLHTTP Request, a message will be displayed.

Dynamic Java Script

Take a look back at Listings above and notice that all of this code is nested directly within script tags.

When JavaScript is coded like that and not put within a method or function body, it's called static JavaScript.

This means that the code is run sometime before the page is displayed to the user.

It's not 100 percent clear from the specification precisely when this code runs and browsers do things differently; still, you're guaranteed that the code is run before users can interact with your page. That's usually XMLHttpRequest obejct is now created by Ajax programmers.

With code setup like this, you'll need to call this method before you do any Ajax work. So you might have something like Listing below

Listing.. Use an XMLHttpRequest creation method

The only concern with this code; and the reason most Ajax programmers don't use this approach
is that it delays error notification. Suppose if we have a complex form with 10 or 15 fields, selection boxes, and the like, and some Ajax code is fired when the user enters text in field
14 (way down the form). At that point, getInfo() runs, tries to create an XMLHttpRequest object, and (for this example) fails.
Then an alert is displayed out to the user, telling them (in so many words) that they can't use this application. But the user has already spent time entering data in the form!
That's pretty annoying and annoyance; is not something that typically entices users back to your site.

In the case where static JavaScript is used, the user is going to get an error as soon as they hit your page. Is that also annoying? Perhaps; it could make users mad that your Web application won't run on their browser. However, it's certainly better than displaying out that same error after they've spent 10 minutes entering information. For that reason alone, I encourage to set up code statically and let users know early on about possible problems.

Sending requests with XMLHttpRequest

Once we have our request object, we can begin the request/response cycle. Remember, XMLHttpRequest's only purpose is to allow you to make requests and receive responses. Everything else -- changing the user interface, swapping out images, even interpreting the data that the server sends back -- is the job of JavaScript, CSS, or other code in your pages. With XMLHttpRequest ready for use, now you can make a request to a server.

Welcome to the sandbox

Ajax has a sandbox security model. As a result, your Ajax code (and specifically, the XMLHttpRequest object) can only make requests to the same domain on which it's running. A lot regarding to security will be learnt in future upcoming articles, but for now realize that code running on a local machine can only make requests to server-side scripts on that local machine. If an Ajax code running on www.xyz.com, it must make requests to scripts that run on www.xyz.com.

Setting the server URL

The first thing to be determined is the url of the server to connect. This isn't specific to Ajax -- obviously you should know how to construct a URL by now -- but is still essential to making a connection. In most applications, you'll construct this URL from some set of static data combined with data from the form your users work with. For example, Listing below shows some JavaScript that grabs the value of the phone number field and then constructs a URL using that data.

Listing.. Building a request URL

Nothing here should trip up. First, the code creates a new variable named phone and assigns the value of the form field with an ID of phone. Listing below shows the HTML for this particular form in which you can see the phone field and its id attribute.

Listing.. The form

Also notice when phone number changed or entered, getInfo() method gets fired shown in Listing above. That method then grabs the number and uses it to construct a URL string stored in the 'url' variable. Remember: Since Ajax code is sandboxed and can only connect to the same domain, one need not have a domain name in your URL. In this example, the script name is lookupCustomer.php. Finally, the phone number is appended to this script as a GET parameter: "phone=" + escape(phone).

Here, escape method is to send the clear text correctly. For example, any spaces in the phone number are converted to "%20" characters, making it possible to pass the characters along in the URL.

Similarly according to requirement, any number of parameters can be added to the query string seperating them with " & ".

Opening the request

With a URL to connect to, request could be configured. This will be accomplished using open() method on your XMLHttpRequest object. This method takes as many as five parameters:

1. request-type: The type of request to send. Typical values are GET or POST, but you can also send HEAD requests.


2. url: The URL to connect.


3. asynch: True if you want the request to be asynchronous and false if it should be a synchronous request. This parameter is optional and defaults to true.


4. username: If authentication is required, you can specify the username here. This is an optional parameter and has no default value.


5. password: If authentication is required, you can specify the password here. This is an optional parameter and has no default value.

Typically, first three will be used. In fact, even when we want to send an asynchronous request, we should specify "true" as the third parameter.

That's the default setting, but it's a nice bit of self-documentation to always indicate if the request is asynchronous or not.

Put it all together; end up with a line that looks a lot like Listing below.

Listing.. Open the request

Once the URL figured out, then this is pretty trivial. For most requests, using GET is sufficient (we will see the situations in which we may want to use POST in future articles); that, along with the URL, is all we need to use open().

A teaser on asynchronicity

Later in the series , significant time will be spent on writing and using asynchronous code. But one should have an idea of why that last parameter in open() is so important.

In a normal request/response model; think Web 1.0 here, the client makes a request to the server.

That request is synchronous; in other words, the client waits for a response from the server.

While the client is waiting, we usually get at least one of several forms of notification that you're waiting:

• An hourglass (on Windows).


• A spinning beachball (on Mac machines).


• The application essentially freezes and sometimes the cursor changes.

This is what makes Web applications in particular feel clunky or slow; the lack of real interactivity. When you push a button, your application essentially becomes unusable until the request you just triggered is responded to. If we've made a request that requires extensive server processing, that wait might be significant (at least for today's multi-processor, DSL, no-waiting world).
An asynchronous request though, does not wait for the server to respond.

You send a request and then your application continues on. Users can still enter data in a Web form, click other buttons, even leave the form.

There will be no freeze of application. The server quietly responds to the request and when it's finished, it let's the original requestor know that it's done (it'll be seen in a moment).

The end result is an application that doesn't feel clunky or slow, but instead is responsive, interactive, and makes feel faster.

This is just one component of Web 2.0, but it's a very important one. All the slick GUI components and Web design paradigms can't overcome a slow, synchronous request/response model.

Sending the request

Once we configure the request with open(), we are ready to send the request. Fortunately, the method for sending a request is named more properly than open(); it's simply called send().
send() takes only a single parameter, the content to send. But before you think too much on that, recall that you are already sending data through the URL itself:

var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);

Although you can send data using send(), we can also send data through the URL itself.

In fact, in GET requests (which will constitute as much as 80 percent of your typical Ajax usage), it's much easier to send data in the URL.

When we start to send secure information or XML, then we need to look at sending content through send(); both secure data and XML messaging could be used in a later article in this series.

When you don't need to pass data along through send(), then just pass null as the argument to this method.

So, to send a request in the example you've seen throughout this article, that's exactly what is needed (see Listing below).

Listing.. Sending the request

Specifying a callback method

At this point, we have done very little that feels new, revolutionary, or asynchronous.

Granted, that little keyword "true" in the open() method sets up an asynchronous request. But other than that, this code resembles programming with Java servlets and JSPs, PHP, or Perl. So what's the big secret to Ajax and Web 2.0?

The secret revolves around a simple property of XMLHttpRequest called onreadystatechange.

First, be sure to understand the process that is created in this code (review Listing above if needed). A request is set up and then made.

Additionally, because this is an asynchronous request, the JavaScript method (getInfo() in the example) will not wait for the server. So the code will continue; in this case, that means that the method will exit and control will return to the form.

Users can keep entering information and the application isn't going to wait on the server.

This creates an interesting question, though:

What happens when the server has finished processing the request?

The answer, at least as the code stands right now, is nothing! Obviously, that's not good, so the server needs to have some type of instruction on what to do when it's finished processing the request sent to it by XMLHttpRequest.

Referencing a function inJavaScript. Since JavaScript is a loosely typed language and you can reference just about anything as a variable.

So if you declare a function called updatePage(), JavaScript also treats that function name as a variable. In other words, you can reference the function in your code as a variable named updatePage

This is where that onreadystatechange property comes into play.

This property allows us to specify a callback method. A callback allows the server to (can you guess?) call back into the web page's code. It gives a degree of control to the server, as well; when the server finishes a request, it looks in the XMLHttpRequest object and specifically at the onreadystatechange property.

Whatever method is specified by that property is then invoked. It's a callback because the server initiates calling back into the Web page; regardless of what is going in the Web page itself.

For example, it might call this method while the user is sitting in her chair, not touching the keyboard; however, it might also call the method while the user is typing, moving the mouse, scrolling, clicking a button ... it doesn't matter what the user is doing.

This is actually where the asynchronicity comes into play: The user operates the form on one level while on another level, the server answers a request and then fires off the callback method indicated by the onreadystatechange property. So you need to specify that method in your code as shown in Listing below

Listing.. Set a callback method

Pay close attention to where in the code this property is set; it's before send() is called. You must set this property before the request is sent, so the server can look up the property when it finishes answering a request. All that's left now is to code the updatePage() which is the focus of the last section in this article.

Handling server responses

When a request is made, your user works happily in the web form (while the server handles the request), and now the server finishes up handling the request. The server looks at the onreadystatechange property and figures out what method to call. Once that occurs, one can think of your application as any other app, asynchronous or not.

In other words, we don't have to take any special action writing methods that respond to the server; just change the form, take the user to another URL, or do whatever else to be done in response of the Server.

In this section, we'll focus on responding to the server and then taking a typical action; changing on the fly part of the form the user sees.

Callbacks and Ajax

We've already seen how to let the server know what to do when it's finished:

Set the onreadystatechange property of the XMLHttpRequest object to the name of the function to run.

When the server has processed the request, automatically that function will be called. We don't need to worry about any parameters to that method. we'll start with a simple method like in Listing.

Listing.. Code the callback method

This just displays a handy alert; to intimate when the server is done. Try this code in your own page, save the page, and then pull it up in a browser (if you want the XHTML from this example, refer back to Listing above). When a phone number and field is left, alert popup should be seen; but click OK and it pops up again ... and again.

Depending on your browser, you'll get two, three, or even four alerts before the form stops popping up alerts. So what's going on? It turns out that you haven't taken into account the HTTP ready state, an important component of the request/response cycle.

HTTP ready states

Earlier, I said that the server, once finished with a request, looks up what method to call in the onreadystatechange property of XMLHttpRequest. That's true, but it's not the whole truth. In fact, it calls that method every time the HTTP ready state changes. So what does that mean? Well, we've got to understand HTTP ready states first.

An HTTP ready state indicates the state or status of a request. It's used to trace if a request has been started, if it's being answered, or if the request/response model has completed. It's also helpful in determining whether it's safe to read whatever response text or data that a server might have supplied. There are 5 Ready states in AJAX Applications:

• 0: The request is uninitialized (before you've called open()).


• 1: The request is set up, but hasn't been sent (before you've called send()).


• 2: The request was sent and is being processed (you can usually get content headers from the response at this point).


• 3: The request is being processed; often some partial data is available from the response, but the server hasn't finished with its response.


• 4: The response is complete; we have server's response and use it.

As with almost all cross-browser issues, these ready states are used somewhat inconsistently. You might expect to always see the ready state move from 0 to 1 to 2 to 3 to 4, but in practice, that's rarely the case. Some browsers never report 0 or 1 and jump straight to 2, then 3, and then 4. Other browsers report all states. Still others will report ready state 1 multiple times. As we saw in the last section, the server called updatePage() several times and each invocation resulted in an alert box popping up; probably which is not intended.

For Ajax programming, the only state you need to deal with directly is readyState 4, indicating that a server's response is complete and it's safe to check the response data and use it. To account for this, the first line in your callback method should be as shown in Listing below.

Listing.. Check the ready state

This change checks to ensure that the server really is finished with the process. Try running this version of the Ajax code and you should only get the alert message one time, which is as it should be.

HTTP status codes

Despite the apparent success of the code in Listing above, there's still a problem;

What happens if server finishing processing and reports an error?

Remember, that server-side code should care if it's being called by Ajax, a JSP, a regular HTML form, or any other type of code; it only has the traditional Web-specific methods of reporting information. And in the Web world, HTTP codes can deal with the various things that might happen in a request.

For example, we've certainly entered a request for a URL, typed the URL incorrectly, and received a 404 error code to indicate a page is missing.

This is just one of many status codes that HTTP requests can receive as a status. In each of these cases, these are codes that result from a completed response. In other words, the server fulfilled the request (meaning the HTTP ready state is 4), but is probably not returning the data expected by the client.
In addition to the ready state then, we also need to check the HTTP status. we are looking for a status code of 200 which simply means okay. With a ready state of 4 and a status code of 200, we are ready to process the server's data and that data should be what we've asked for. Add another status check to your callback method as shown in Listing below.

Listing.. Check the HTTP status code

To add more robust error handling, with minimal complication; we might add a check or two for other status codes; check out the modified version of updatePage() in Listing below.

Listing.. Adding some light error check

Now change the URL in your getInfo() to a non-existent URL and see what happens. An alert should say URL does not exists; perfect! This's hardly going to handle every error condition, but it's a simple change that covers 80 percent of the problems that can occur in a typical Web application.

Reading the response text

Now that we make sure the request was completely processed (through the ready state) and the server gave you a normal, okay response (through the status code), one can finally deal with the data sent back by the server. This is conveniently stored in the responseText property of the XMLHttpRequest object.

Details about what the text in responseText looks like, in terms of format or length, is left intentionally displayed. This allows the server to set this text to virtually anything. For instance, one script might return comma-separated values, another pipe-separated values (the pipe is the | character), and another may return one long string of text. It's all up to the server.

In the case of the example used in this article, the server returns a customer's last order and then their address, separated by the pipe symbol. The order and address are both then used to set values of elements on the form; Listing below shows the code that updates the display.

Listing.. Dealing with server's response

First, the responseText is pulled and split on the pipe symbol using the JavaScript split() method. The resulting array of values is dropped into response. The first value, the customer's last order; is accessed in the array as response[0] and is set as the value of the field with an ID of "order." The second value in the array, at response[1], is the customer's address and it takes a little more processing. Since the lines in the address are separated by normal line separators (the "\n" character), the code needs to replace these with XHTML-style line separators, <br /> s. That's accomplished through the use of the replace() function along with a regular expression. Finally, the modified text is set as the inner HTML of a div in the HTML form. The result is that the form suddenly is updated with the customer's information.

Before this article closed up; another important property of XMLHttpRequest is called responseXML. Guess what that property contains?

An XML response in the event that the server chooses to respond with XML. Dealing with an XML response is quite different than dealing with plain text and involves parsing, the Document Object Model (DOM), and several other considerations.

More will be learnt in future articles regarding to XML and DOM parsing. Still, because responseXML commonly comes up in discussions surrounding responseText, it's worth mentioning here.

For many simple Ajax applications, responseText is all you need, but you'll soon learn about dealing with XML through Ajax applications as well.

Ajax it's a powerful approach to building Web sites and it's not nearly as hard to learn as an entire new language.
It is mainly based on Javascript and XML
Before seeing what Ajax is, though, let's spend just a few moments understanding what Ajax does.

When an application is written today, we have two basic choices:

• Desktop applications
  Desktop applications usually installed completely on your computer. They might use the Internet to download updates, but the code that runs these applications resides on your desktop.
  


• Web applications
  There's no surprise here -- run on a Web server somewhere and you access the application with your Web browser.
  
  

More important than where the code for these applications runs, is how they do interact. 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.

On the other hand, Web applications are usually up-to-the-second current and they provide services you could never get on your desktop (yahoo and google). However, with the power of the Web comes waiting -- waiting for a server to respond, waiting for a screen to refresh, waiting for a request to come back and to generate a new page.
As you might already be suspecting, Ajax attempts to reduce the gap between the functionality and interactivity of a desktop application and the always-updated Web application.
Here dynamic user interfaces and fancy controls can be used.
So what are you waiting for? Start looking at Ajax and how to turn your clunky Web interfaces into responsive Ajax applications.

Here are the basic technologies involved in Ajax applications:

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

The XMLHttpRequest object

The first object you want to understand is probably the one that's newest to you; it's called XMLHttpRequest. This is a JavaScript object and is created as simply as shown below..

Listing.. Create a new XMLHttpRequest object

This object will be discussed in next part, but for now realize this object that handles all your server communication. Before going forward, stop and think about that -- it's the JavaScript technology through the XMLHttpRequest object that talks to the server. That's not the normal application flow and it's where Ajax gets much of its magic.Getting a Request object
With a basic overview under your belt, you're ready to look at a few specifics. Since XMLHttpRequest is central to Ajax applications -- and probably new to many of you -- I'll start there. As you saw in Listing 1, it should be pretty easy to create this object and use it, right? Wait a minute.
Remember those pesky browser wars from a few years back and how nothing worked the same across browsers? Well, believe it or not, those wars are still going on albeit on a much smaller scale. And, surprise: XMLHttpRequest is one of the victims of this war. So you'll need to do a few different things to get an XMLHttpRequest object going. I'll take your through it step by step.
Working with Microsoft browsersMicrosoft's browser, Internet Explorer, uses the MSXML parser for handling XML (you can find out more about MSXML in Resources). So when you write Ajax applications that need to work on Internet Explorer, you need to create the object in a particular way.
However, it's not that easy. MSXML actually has two different versions floating around depending on the version of JavaScript technology installed in Internet Explorer, so you've got to write code that handles both cases. Look at Listing below for the code that you need to create an XMLHttpRequest on Microsoft browsers.

Listing.. Create an XMLHttpRequest object on Microsoft browsers

All of this won't make sense , but its OK. You'll dig into JavaScript programming, error handling, conditional compilation, and more before this series is finished. For now, you want to get two core lines into your head:
xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
and
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");.

In whole, this code tries to create the object using one version of MSXML; if that fails, it then creates the object using the other version. Nice, huh? If neither of these work, the xmlHttp variable is set to false, to tell your code know that something hasn't worked. If that's the case, you've probably got a non-Microsoft browser and need to use different code to do the job.
Dealing with non-Microsoft browsers
If Internet Explorer isn't your browser of choice or you write code for non-Microsoft browsers, then you need different code. In fact, this is the really simple line of code you saw back in first Listing..
var xmlHttp = new XMLHttpRequest object;
This simpler line creates an XMLHttpRequest object in Mozilla, Chrome, Safari and several browsers any form or fashion.
The key is to support all browsers. Who wants to write an application that works just on Internet Explorer or an application that works just on non-Microsoft browsers? Worse yet, do you want to write your application twice? Of course not! So your code combines support for both Internet Explorerand non-Microsoft browsers. Listing below shows the code to do that.

Listing... Create an XMLHttpRequest object the multi-browser way

Focus exclusively on XMLHttpRequest. The core of this code breaks down into three steps:

1. Create a variable, xmlHttp, to reference the XMLHttpRequest object that you will create.

2. Try and create the object in Microsoft browsers:

* Try and create the object using the Msxml2.XMLHTTP object.

* If that fails, try and create the object using the Microsoft.XMLHTTP object.

3. If xmlHttp still isn't set up, create the object in a non-Microsoft way.

At the end of this process, xmlHttp should reference a valid XMLHttpRequest object, no matter what browser your users run.
So you now understand Ajax and have a basic idea about the XMLHttpRequest object and how to create it.
If read read closely, one can realize that it's the JavaScript technology that talks to any Web application on the server rather than your submitting HTML form to application.
What's the missing piece? How to actually use XMLHttpRequest. Since this is critical code that you'll use in some form in every Ajax application you write, take a quick tour through what a basic request/response model with Ajax looks like.
Making a request

You have your shiny new XMLHttpRequest object; now take it for a spin. First, you need a JavaScript method that your Web page can call (like when a user types in text or selects an option from a menu). Then, you'll follow the same basic outline in almost all of your Ajax applications:

1. Get whatever data you need from the Web form.


2. Build the URL to connect to.


3. Open a connection to the server.


4. Set up a function for the server to run when it's done.


5. Send the request.

Listing is a sample of an Ajax method that does these very things, in this order:

Listing.. Make a request with Ajax

A lot of this is self-explanatory. The first bit of the code uses basic JavaScript code to grab the values of a few form fields. Then the code sets up a PHP script as the destination to connect to. Notice how the URL of the script is specified and then the city and state (from the form) are appended to this using simple GET parameters.

Next, a connection is opened; here's the first place you see XMLHttpRequest in action again. The method of connection is indicated (GET), as well as the URL to connect to. The final parameter, when set to true, requests an asynchronous connection (thus making this Ajax). If you used false, the code would wait around on the server when the request was made and not continue until a response was received. By setting this to true, your users can still use the form (and even call other JavaScript methods) while the server is processing this request in the background.

The onreadystatechange property of xmlHttp (remember, that's your instance of the XMLHttpRequest object) allows you to tell the server what to do when it does finish running (which could be in five minutes or five hours). Since the code isn't going to wait around for the server, you'll need to let the server know what to do so you can respond to it. In this case, a specific method -- called updatePage() -- will be triggered when the server is finished processing your request.

Finally, send() is called with a value of null. Since you've added the data to send to the server (the city and state) in the request URL, you don't need to send anything in the request. So this fires off your request and the server can do what you asked it to do.

If you don't get anything else out of this, notice how straightforward and simple this is! Other than getting the asynchronous nature of Ajax into your head, this is relatively simple stuff. You'll appreciate how it frees you up to concentrate on cool applications and interfaces rather than complicated HTTP request/response code.

The code at last Listing is about as easy as it gets. The data is simple text and can be included as part of the request URL. GET sends the request rather than the more complicated POST. There's no XML or content headers to add, no data to send in the body of the request -- this is Ajax simplicity, in other words.

Don't get panic; things will become more complicated as series progresses. You'll learn sending POST requests, setting headers and content types, encoding XML in request, how to add security to your request so on!

Don't worry about this stuff for now; get your concentration around basics, and sooner you could build up a whole set of Ajax tools.

Handling the response

Now time to handle the servers' response. You really only need to know two things at this point:

• Don't do anything until the xmlHttp.readyState property is equal to 4.


• The server will stuff it's response into the xmlHttp.responseText property.

The first of these ready states is going to take up the bulk of the next article. For now, simply check for a certain value (4), things will work.
The second one using xmlHttp.responseText property for getting server's response -- is easy. Next Listing provides an example of a method that the server can call based on the values sent in previous listing.

Listing.. Handle the server's response

This code is not difficult or complicated. Waits until server sends with proper readyState and then uses the value that the server returns to set the value of another form field; with this suddenly a pincode will appear in the control provided for it -- but the user never had to click a button!. That's the feel of desktop that is described earlier. Responsiveness, a dynamic feel, and more, or less like a Javacsript code.
Readers might notice that the pincode field is normal text field. Once the server returns the ZIP code and the updatePage() method sets the value of that field with the city/state ZIP code, users can override the value.

PHP supports eight primitive types.

Four scalar types

1. boolean
2. integer
3. float (floating-point number, or 'double')
4. string

Two compound types

1. Array
2. object

And finally two special types:

1. resource
2. NULL

We introduce some pseudo-types for readability:

1. mixed
2. number
3. callback

You may also find some references to the type "double". Consider double the same as float, the two names exist only for historic reasons.

The type of a variable is usually not set by the programmer; rather, it is decided at runtime by PHP depending on the context in which that variable is used.

Note: If you want to check out the type and value of a certain expression, use var_dump().


If you simply want a human-readable representation of the type for debugging, use gettype(). To check for a certain type, do not use gettype(), but use the is_type functions. Some examples:


If you would like to force a variable to be converted to a certain type, you may either cast the variable or use the settype() function on it.
Note that a variable may be evaluated with different values in certain situations, depending on what type it is at the time.

<HTML>
Example
<body>
This is normal text (HTML)

<?php
echo "Hi: PHP Line";
?>

</body>
</HTML>