AJAX: Asynchronous Event Handling Sunnie Chung

Size: px

Start display at page:

Download "AJAX: Asynchronous Event Handling Sunnie Chung"

Alexina White
6 years ago
Views:

AJAX: Asynchronous Event Handling Sunnie Chung http://adaptivepath.org/ideas/ajax-new-approach-web-applications/ http://stackoverflow.

1 AJAX: Asynchronous Event Handling Sunnie Chung 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. It s a model adapted from the Web s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn t necessarily make it good for software applications. Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).

2 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. Obviously, if we were designing the Web from scratch for applications, we wouldn t make users wait around. 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? HOW AJAX IS DIFFERENT 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.

Figure 2: The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).

3 Figure 2: The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom). Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn t require a trip back to the server such as simple data validation, editing data in memory, and even some navigation the engine handles on its own. If the engine needs something from the server in order to respond if it s submitting data for processing, loading additional interface code, or retrieving new data the engine makes those requests asynchronously, usually using XML, without stalling a user s interaction with the application.

4 Does asynchronous call always create a new thread? Example: If JavaScript is single threaded then how can it do an async postback? Is it actually blocking until it gets a callback? If so, is this really an async call? ANSWER : NO, AJAX call does NOT create a new thread! Asynchronous programming is a paradigm of programming that is principally single threaded, i.e. "following one thread of continuous execution". You refer to javascript, so lets discuss that language, in the environment of a web browser. A web browser runs a single thread of javascript execution in each window, it handles events (such as onclick="somefunction()") and network connections (such as xmlhttprequest calls). <script> function performrequest() { xmlhttp.open("get", "someurl", true);

5 xmlhttp.onreadystatechange = function() { if (xmlhttp.readystate == 4) { alert(xmlhttp.responsetext); xmlhttp.send(sometext); </script> <span onclick="performrequest()">perform request</span> (This is a nonworking example, for demonstration of concepts only). In order to do everything in an asynchronous manner, the controlling thread (this one controlling thread controls all the events in one window thread) has what is known as a 'main loop'. A main loop looks kind of like this: while (true) { event = nextevent(all_event_sources); handler = findeventhandler(event); handler(event); It is important to note that this is not a 'busy loop'. This is kind of like a sleeping thread, waiting for activity to occur. Activity could be input from the user (Mouse Movement, a Button Click, Typing), or it could be network activity (The response from the server). So in the example above, 1. When the user clicks on the span, a ButtonClicked event would be generated, findeventhandler() would find the onclick event on the span tag, and then that handler would be called with the event. 2. When the xmlhttp request is created, it is added to the all_event_sources list of event sources. 3. After the performrequest() function returns, the mainloop is waiting at the nextevent() step waiting for a response. At this point there is nothing 'blocking' further events from being handled. 4. The data comes back from the remote server, nextevent() returns the network event, the event handler is found to be the onreadystatechange() method, that method is called, and an alert() dialog fires up. It is worth noting that alert() is a blocking dialog. While that dialog is up, no further events can be processed. It's an eccentricity of the javascript model of web pages that we have a readily available method that will block further execution within the context of that page. The Javascript model is single-threaded. An asynchronous call is not a new thread, but rather interrupts an existing thread. It's analogous to interrupts in a kernel.

6 Yes it makes sense to have asynchronous calls with a single thread. Here's how to think about it: When you call a function within a single thread, the state for the current method is pushed onto a stack (i.e. local variables). The subroutine is invoked and eventually returns, at which time the original state is popped off the stack. With an asynchronous callback, the same thing happens! The difference is that the subroutine is invoked by the system, not by the current code invoking a subroutine. Very simple question: suppose I have the following js/jquery code dosomething(); $.get(url, callback); dosomethingelse(); I understand that right after the GET request is sent dosomethingelse() starts being executed. Now suppose that the server's reply arrives while dosomethingelse() is executing. What happens? Does the callback run in a separate thread in parallel to dosomethingelse()? Does the execution of dosomethingelse() pause until the callback runs and returns? Does the callback only get called once dosomethingelse() has returned? JavaScript in web browsers is single-threaded, by design. That means that although the ajax call may start immediately (and be processed by another thread in the browser), your callback won't happen until the JavaScript interpreter is next idle. Things to do get queued up waiting for the interpreter to become idle and process them. No, JavaScript in web browsers is single-threaded, by design. That means that although the ajax call may start immediately (and be processed by another thread in the browser), your callback won't happen until the JavaScript interpreter is next idle. Things to do get queued up waiting for the interpreter to become idle and process them. Does the callback run in a separate thread in parallel to dosomethingelse()? No, the callback will run in the same logical thread as dosomethingelse. (It would be implementation-dependant whether that's the same actual underlying OS thread, but you have no way of knowing and you don't care; logically, it's the same thread.) Does the execution of dosomethingelse() pause until the callback runs and returns? By default, the get will be asynchronous, so no. dosomethingelse initiates the request, but then continues. (It's possible to do a synchronous get via the underlying XmlHttpRequest mechanism,

7 but it's a very bad idea -- tends to lock up the UI of the browser completely while the request is running, which is ugly -- and I don't know how you do it with jquery.) Does the callback only get called once dosomethingelse() has returned? With an asynchronous get (the usual kind), you can be certain that dosomethingelse will finish before the callback gets called, yes. This is because the JavaScript interpreter will only do one thing at a time, and it doesn't switch to doing a new thing until it's done with the current one. So although dosomethingelse triggers the get (and the get may be processed by other, non- JavaScript threads in parallel to JavaScript), your callback won't happen until after the interpreter is done with dosomethingelse and anything that called it. I wouldn't be surprised if at some point we start getting multiple threads in browser-based JavaScript, but if and when we do, it'll have to be explicit, since we all happily assume one thread for the moment. Example Code: loaddoc("url-1", myfunction1); loaddoc("url-2", myfunction2); function loaddoc(url, cfunction) { var xhttp; xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if (this.readystate == 4 && this.status == 200) { cfunction(this); ; xhttp.open("get", url, true); xhttp.send(); function myfunction1(xhttp) { // action goes here function myfunction2(xhttp2) { // action goes here do something else(); Execution Sequence:

8 1)loadDoc("url-1", myfunction1); 1_1 xhttp.open("get", url-1, true); 1_2 xhttp.send(); 2) loaddoc("url-2", myfunction2); 2_1 xhttp2.open("get", url-2, true); 2_2 xhttp2.send(); 3) do something else(); When the browser completed with do something else() and it became idle, then 4) myfunction1(xhttp) if server sent url-1 file first and ready Or myfunction1(xhttp2) if server sent url-2 file first and ready Then when the browser completed and it became idle, then 5) myfunction1(xhttp2) if server sent url-2 file next and ready after url-1 Or myfunction1(xhttp1) if server sent url-1 file next and ready after url-2 Other Notes: Difference between window.location.href and top.location.href top.location.href = 'somepage.html'; means loading somepage.html in the main browser window. Two other interesting objects are self and parent.... top refers to the window object which contains all the current frames ( father of the rest of the windows ). window is the current window window.location.href returns the location of the current page. top.location.href (which is an alias of window.top.location.href) returns the location of the topmost window in the window hierarchy. If a window has no parent, top is a reference to itself (in other words, window === window.top). top is useful both when you're dealing with frames and when dealing with windows which have been opened by other pages. For example, if you have a page called test.html with the following script: var newwin=window.open('about:blank','test','width=100,height=100'); newwin.document.write('<script>alert(top.location.href);</script>');

9 The resulting alert will have the full path to test.html not about:blank, which is what window.location.href would return. To answer your question about redirecting, go with window.location.assign(url);

AJAX Programming Overview. Introduction. Overview

AJAX Programming Overview. Introduction. Overview AJAX Programming Overview Introduction Overview In the world of Web programming, AJAX stands for Asynchronous JavaScript and XML, which is a technique for developing more efficient interactive Web applications.