ajax英文文献.doc

Research on Web Applications Using Ajax New TechnologiesAbstractAjax is really several technologies, each flourishing in its own right, coming together in powerful new ways, which consists of HTML, JavaScript. technology, DHTML, and DOM, is an outstanding approach that helps to transform clunky Web interfaces into interactive Ajax applications. After the definition to Ajax, how to make asynchronous requests with JavaScript and Ajax was introduced. At the end, advanced requests and responses in Ajax were put forward. Keywords-component; Ajax; JavaScript; XMLHttpRequest; Web Applications I. INTRODUCTION Ajax is shorthand for Asynchronous JavaScript and XML (and DHTML, and so on). The phrase was coined by Jesse James Garrett of Adaptive Path and is, according to Jesse, not meant to be an acronym. However, Ajax is far more than just a fad; its a powerful approach to building Web sites and its not nearly as hard to learn as an entire new language. Figure 1. The traditional model for web applications (left) compared to the Ajax model (right)Ajax isnt a technology. Its really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates: . standards-based presentation using XHTML and CSS; . dynamic display and interaction using the Document Object Model; . data interchange and manipulation using XML and XSLT; . asynchronous data retrieval using XMLHttpRequest; . JavaScript binding everything together. 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, crunching numbers, talking to various legacy systems and then returns an HTML page to the client. Its a model adapted from the Webs original use as a hypertext medium, but as fans of the Elements of User Experience know, what makes the Web good for hypertext doesnt necessarily make it good for software applications. This approach makes a lot of technical sense, but it doesnt make for a great user experience. While the server is doing its thing, whats the user doing? Thats right, waiting. And at every step in a task, the user waits some more. Obviously, we wouldnt make users wait around in designing the Web from scratch for applications. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all? II. MAKE ASYNCHRONOUS REQUESTS WITH JAVASCRIPT AND AJAX Most Web applications use a request/response model that gets an entire HTML page from the server. The result is a back-and-forth that usually involves clicking a button, waiting for the server, clicking another button, and then waiting some more. With Ajax and the XMLHttpRequest object, we can use a request/response model that never leaves users waiting for a server to respond. A. Introducing XMLHttpRequest XMLHttpRequest has actually been around in several browsers for quite a while, which is the key to Web 2.0, Ajax, and pretty much everything. To give a really quick overview, these are just a few of the methods and properties will be used on this object: . open (): Sets up a new request to a server. . send (): Sends a request to a server. . abort (): Bails out of the current request. . readyState: Provides the current HTML ready state. . responseText: The text that the server sends back to respond to a request. Each of these methods and properties relate to sending a request and dealing with a response. In fact, if we saw every method and property of XMLHttpRequest, they would all relate to that very simple request/response model. So clearly, we wont learn about an amazing new GUI object or some sort of super-secret approach to creating user interaction; programmers will work with simple requests and simple responses. It might not sound exciting, but careful use of this one object can totally change our applications. First, we need to create a new variable and assign it to an instance of the XMLHttpRequest object. Thats pretty simple in JavaScript, just use the new keyword with the object name, like in Fig.2. Figure 2. Create a new XMLHttpRequest objectIn real life, things can go wrong and this code doesnt provide any error-handling. A slightly better approach is to create this object and have it gracefully fail if something goes wrong. For example, many older browsers (believe it or not, people are still using old versions of Netscape Navigator) dont support XMLHttpRequest and Web applications need to let those users know that something has gone wrong. Fig.3 shows how to create this object so if something fails, it throws out a JavaScript alert. Figure 3. Create XMLHttpRequest with some error-handling abilitiesIt turns out that Microsoft supports Ajax, but calls its version of XMLHttpRequest something different. In fact, it calls it several different things. When using a newer version of Internet Explorer, programmers need to use an object called Msxml2.XMLHTTP. Some older versions of Internet Explorer use Microsoft. XMLHTTP to support these two object types (without losing the support already have for non-Microsoft browsers). Check out Fig.4 which adds Microsoft support to the code weve already seen. In fact, Microsofts newest version of Internet Explorer version 7.0, set to come out late in 2006 - is supposed to move to supporting XMLHttpRequest directly, allowing programmers to use the new keyword instead of all the Msxml2.XMLHTTP creation code. Figure 4. Add support for Microsoft browsersB. Sending requests with XMLHttpRequest XMLHttpRequests only purpose is to allow developers to make requests and receive responses. Everything else is 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 Web pages. With XMLHttpRequest ready for use, a request to a server can be made. Figure 5. Build a request URLThe URL of the server to connect to is the first thing need to be determined. This isnt specific to Ajax - obviously developers should know how to construct a URL by now but is still essential to making a connection. In most applications, developers will construct this URL from some set of static data combined with data from the form users work with. For example, Fig.5 shows some JavaScript that grabs the value of the phone number field and then constructs a URL using that data. First, the code creates a new variable named phone and assigns the value of the form field with an ID of phone. III. ADVANCED REQUESTS AND RESPONSES IN AJAX As the centerpiece of an Ajax application, XMLHttpRequest object handles requests to a server-side application or script, and also deals with return data from that server-side component. Every Ajax application uses the XMLHttpRequest object, so developers will want to be intimately familiar with it to make their Ajax applications perform and perform well. There are three key parts of this request object: the HTTP ready state, the HTTP status code, the types of requests that can be made. A. The HTTP ready state The XMLHttpRequest object has a property called readyState. This property ensures that a server has completed a request and typically, a callback function uses the data from the server to update a Web form or page. Fig. 6 shows a simple example of this. Figure 6. Deal with a servers response in a callback functionThis is definitely the most common (and most simple) usage of ready states. As you might guess from the number 4, though, there are several other ready states. . 0: The request is uninitialized (before open () are called). . 1: The request is set up, but not sent (before send () are called). . 2: The request was sent and is in process (content headers can usually be get from the response at this point). Figure 7. Callback function that ignores the status code. 3: The request is in process; often some partial data is available from the response, but the server isnt finished with its response. . 4: The response is complete; the servers response can be get and can use it. B. The HTTP status code Through Web browser we have probably already seen several of these: 401: Unauthorized; 403: Forbidden; 404: Not Found. In many Ajax applications, well see a callback function that checks for a ready state and then goes on to work with the data from the server response, as in Fig. 7. This turns out to be a short-sighted and error-prone approach to Ajax programming. If a script requires authentication and our request do not provide valid credentials, the server will return an error code like 403 or 401. However, the ready state will be set to 4 since the server answered the request (even if the answer wasnt what developers wanted or expected for their request). As a result, the user is not going to get valid data and might even get a nasty error when developers JavaScript tries to use non-existent server data. It takes minimal effort to ensure that the server not only finished with a request, but returned an Everything is OK status code. That code is 200 and is reported through the status property of the XMLHttpRequest object. To make sure that not only did the server finish with a request but that it also reported an OK status, add an additional check in callback function as shown in Fig.8. Figure 8. Check for a valid status codeWith the addition of a few lines of code, developers can be certain that if something does go wrong, users will get a (questionably) helpful error message rather than seeing a page of garbled data with no explanation. C. Additional request types To take control of the XMLHttpRequest object, consider this one last stop add HEAD requests to repertoire. Actually making a HEAD request is quite trivial; simply call the open() method with HEAD instead of GET or POST as the first parameter, as shown in Fig. 9. Figure 9. Make a HEAD request with AjaxWhen developers make a HEAD request like this, the server doesnt return an actual response as it would for a GET or POST request. Instead, the server only has to return the headers of the resource which include the last time the content in the response was modified, whether the requested resource exists, and quite a few other interesting informational bits. Developers can use several of these to find out about a resource before the server has to process and return that resource. The easiest thing can do with a request like this is to simply spit out all of the response headers. This gives a feel for whats available to through HEAD requests. Fig. 10 provides a simple callback function to output all the response headers from a HEAD request. Figure 10. Print all the response headers from a HEAD requestOne area where we will find a HEAD request useful is to check the content length or even the content type. This allows developers to determine if a huge amount of data will be sent back to process a request or if the server will try to return binary data instead of HTML, text, or XML (which are all three much easier to process in JavaScript than binary data). In these cases, we just use the appropriate header name and pass it to the getResponseHeader () method on the XMLHttpRequest object. So to get the length of a response, just call request.getResponseHeader(Content-Length), use request.getResponseHeader(Content-Type) to get the content type. In many applications, making HEAD requests adds no functionality and might even slow down a request (by forcing a HEAD request to get data about the response and then a subsequent GET or POST request to actually get the response). However, in the event that we are unsure about a script or server-side component, a HEAD request can allow us to get some basic data without dealing with response data or needing the bandwidth to send that response. IV. CONCLUSION Ajax atte