http://help.dottoro.com/ljqlhagh.php

에서 참조

Creates an XML document object.

Note: The createDocument method is supported in Internet Explorer from version 9, but it creates an HTML document, not an XML document.

Syntax:

object.createDocument (namespaceURI, qualifiedName, docTypeObj);

You can find the related objects in the Supported by objects section below.

Parameters:

namespaceURI Required. String that specifies the namespace URI for the documentElement (root node). qualifiedName Required. String that specifies the name of the documentElement (root node). If an empty string is specified, the new XML document will have no root node. docTypeObj Required. Reference to a doctype object that specifies the document type of the XML document. Use the createDocumentType method to create a doctype object. Set to null if no document type is needed.

Return value:

Returns the newly created XMLDocument object.

Understanding callback functions in Javascript

Callback functions are extremely important in Javascript. They’re pretty much everywhere. Originally coming from a more traditional C/Java background I had trouble with this (and the whole idea of asynchronous programming), but I’m starting to get the hang of it. Strangely, I haven’t found any good introductions to callback functions online — I mainly found bits of documentation on the call() and apply() functions, or brief code snippits demonstrating their use — so, after learning the hard way I decided to try to write a simple introduction to callbacks myself.

Functions are objects

To understand callback functions you first have to understand regular functions. This might seen like a “duh” thing to say, but functions in Javascript are a bit odd.

Functions in Javascript are actually objects. Specifically, they’re Function objects created with the Function constructor. A Function object contains a string which contains the Javascript code of the function. If you’re coming from a language like C or Java that might seem strange (how can code be a string?!) but it’s actually run-of-the-mill for Javascript. The distinction between code and data is sometimes blurred.

1 // you can create a function by passing the
2 // Function constructor a string of code
3 var func_multiply = new Function("arg1", "arg2", "return arg1 * arg2;");
4 func_multiply(5,10); // => 50

One benefit of this function-as-object concept is that you can pass code to another function in the same way you would pass a regular variable or object (because the code is literally just an object).

Passing a function as a callback

Passing a function as an argument is easy.

01 // define our function with the callback argument
02 function some_function(arg1, arg2, callback) {
03     // this generates a random number between
04     // arg1 and arg2
05     var my_number = Math.ceil(Math.random() *
06         (arg1 - arg2) + arg2);
07     // then we're done, so we'll call the callback and
08     // pass our result
09     callback(my_number);
10 }
11 // call the function
12 some_function(5, 15, function(num) {
13     // this anonymous function will run when the
14     // callback is called
15     console.log("callback called! " + num);
16 });

It might seem silly to go through all that trouble when the value could just be returned normally, but there are situations where that’s impractical and callbacks are necessary.

Don’t block the way

Traditionally functions work by taking input in the form of arguments and returning a value using a return statement (ideally a single return statement at the end of the function: one entry point and one exit point). This makes sense. Functions are essentially mappings between input and output.

Javascript gives us an option to do things a bit differently. Rather than wait around for a function to finish by returning a value, we can use callbacks to do it asynchronously. This is useful for things that take a while to finish, like making an AJAX request, because we aren’t holding up the browser. We can keep on doing other things while waiting for the callback to be called. In fact, very often we are required (or, rather, strongly encouraged) to do things asynchronously in Javascript.

Here’s a more comprehensive example that uses AJAX to load an XML file, and uses the call() function to call a callback function in the context of the requested object (meaning that when we call the this keyword inside the callback function it will refer to the requested object):

01 function some_function2(url, callback) {
02     var httpRequest; // create our XMLHttpRequest object
03     if (window.XMLHttpRequest) {
04         httpRequest = new XMLHttpRequest();
05     } else if (window.ActiveXObject) {
06         // Internet Explorer is stupid
07         httpRequest = new
08             ActiveXObject("Microsoft.XMLHTTP");
09     }
10   
11     httpRequest.onreadystatechange = function() {
12         // inline function to check the status
13         // of our request
14         // this is called on every state change
15         if (httpRequest.readyState === 4 &&
16                 httpRequest.status === 200) {
17             callback.call(httpRequest.responseXML);
18             // call the callback function
19         }
20     };
21     httpRequest.open('GET', url);
22     httpRequest.send();
23 }
24 // call the function
25 some_function2("text.xml", function() {
26     console.log(this);
27 });
28 console.log("this will run before the above callback");

In this example we create the httpRequest object and load an XML file. The typical paradigm of returning a value at the bottom of the function no longer works here. Our request is handled asynchronously, meaning that we start the request and tell it to call our function when it finishes.

We’re using two anonymous functions here. It’s important to remember that we could just as easily be using named functions, but for sake of brevity they’re just written inline. The first anonymous function is run every time there’s a state change in our httpRequest object. We ignore it until the state is 4 (meaning it’s done) and the status is 200 (meaning it was successful). In the real world you’d want to check if the request failed, but we’re assuming the file exists and can be loaded by the browser. This anonymous function is assigned to httpRequest.onreadystatechange, so it is not run right away but rather called every time there’s a state change in our request.

When we finally finish our AJAX request, we not only run the callback function but we use the call() function. This is a different way of calling a callback function. The method we used before of just running the function would work fine here, but I thought it would be worth demonstrating the use of the call() function. Alternatively you could use the apply() function (the difference between the two is beyond the scope of this tutorial, but it involves how you pass arguments to the function).

The neat thing about using call() is that we set the context in which the function is executed. This means that when we use the this keyword inside our callback function it refers to whatever we passed as the first argument for call(). In this case, when we refer to this inside our anonymous callback function we are referring to the responseXML from the AJAX request.

Finally, the second console.log statement will run before the first, because the callback isn’t executed until the request is over, and until that happens the rest of the code goes right on ahead and keeps running.

Wrapping it up

Hopefully now you should understand callbacks well enough to use them in your own code. I still find it hard to structure code that is based around callbacks (it ends up looking like spaghetti… my mind is too accustomed to regular structured programming), but they’re a very powerful tool and one of the most interesting parts of the Javascript language.

https://developer.mozilla.org/en-US/docs/DOM/XMLHttpRequest/Using_XMLHttpRequest

에서 참조

XMLHttpRequest makes sending HTTP requests very easy.  You simply create an instance of the object, open a URL, and send the request.  The HTTP status of the result, as well as the result’s contents, are available in the request object when the transaction is completed. This page outlines some of the common and even slightly obscure use cases for this powerful JavaScript object.

Types of requests

A request made via XMLHttpRequest can fetch the data in one of two ways, asynchronously or synchronously. The type of request is dictated by the optional async property that is set on the XMLHttpRequest .open() method. If this property is set to false, then the XMLHttpRequest will be processed synchronously, otherwise the process will be done asynchronously. A detailed discussion and demonstrations of these two types of requests can be found on the synchronous and asynchronous requests page.

Handling responses

There are several types of response attributes defined by the W3C specification for XMLHttpRequest.  These tell the client making the XMLHttpRequest important information about the status of the response. For many use cases this is as straightforward as the following example:

1
2
3
4
5
6
7
8
var request = new XMLHttpRequest();
request.open('GET', 'http://www.mozilla.org', false);
request.send(); // because of "false" above, will block until the request is done 
                // and status is available. Not recommended, however it works for simple cases.
  
if (request.status === 200) {
  console.log(request.responseText);
}

There are some situations where the contents of a remote response from an XMLHttpRequest may not be handled as easily as the case above. A few of these cases where dealing with reponseXML and responseText involves some manipulation and analysis are outlined in the following sections.

Analyzing and manipulating the responseXML property

If you use XMLHttpRequest to get the content of a remote XML document, the responseXML property will be a DOM Object containing a parsed XML document, which can be hard to manipulate and analyze. There are four primary ways of analyzing this XML document:

  1. Using XPath to address (point to) parts of it.
  2. Using JXON to convert it into a JavaScript Object tree.
  3. Manually Parsing and serializing XML to strings or objects.
  4. Using XMLSerializer to serialize DOM trees to strings or to files.
  5. RegExp can be used if you always know the content of the XML document beforehand. You might want to remove line breaks, if you use RegExp to scan with regard to linebreaks. However, this method is a “last resort” since if the XML code changes slightly, the method will likely fail.

Analyzing and manipulating a responseText property containing an HTML document

Note: The W3C XMLHttpRequest specification has added HTML parsing support to XMLHttpRequest, which originally supported only XML parsing. This feature allows Web apps to obtain an HTML resource as a parsed DOM using XMLHttpRequest.responseXML property. Read the article about HTML in XMLHttpRequest for details.

If you use XMLHttpRequest to get the content of a remote HTML webpage, the responseText property is a string containing a “soup” of all the HTML tags, which can be hard to manipulate and analyze. There are three primary ways of analyzing this HTML soup string:

  1. Safely parsing with nsIScriptableUnescapeHTML will quickly convert the HTML string into DOM, while stripping out JavaScript and other advanced elements, including the <head> of the webpage.
  2. RegExp can be used if you always know the content of the HTML responseText beforehand. You might want to remove line breaks, if you use RegExp to scan with regard to linebreaks. However, this method is a “last resort” since if the HTML code changes slightly, the method will likely fail.
  3. Using a hidden chrome or content-level iframe to load up the webpage can also be done to then manipulate it as DOM, however there are security risks to giving remote code this level of privileged access, which can cause issues for the review of your addon. For example, if a webpage executes the common “document.location = redirecttothispage.html” command on load, this will get interpreted as changing the browser chrome location (document.location in an extension) as opposed to the webpage location (content.document.location in an extension), thus destroying all browser components. Alternatively, and somewhat safer, a responseText string attained through a XMLHttpRequest can be analyzed using RegExp to remove potential JavaScript problems, then loaded into the hidden iframe that you have set up:
document.getElementById("hiddenXULiframe").contentWindow.document.body.innerHTML = req.responseText

Using FormData objects

The FormData object lets you compile a set of key/value pairs to send using XMLHttpRequest. Its primarily intended for use in sending form data, but can be used independently from forms in order to transmit keyed data. The transmitted data is in the same format that the form’s submit() method would use to send the data if the form’s encoding type were set to “multipart/form-data”. FormData objects can be utilized in a number of ways with an XMLHttpRequest. For examples and explanations of how one can utilize FormData with XMLHttpRequests see the Using FormData Objects page.

Handling binary data

Although XMLHttpRequest is most commonly used to send and receive textual data, it can be used to send and receive binary content. There are several well tested methods for coercing the response of an XMLHttpRequest into sending binary data. These involve utilizing the .overrideMimeType() method on the XMLHttpRequest object and is a workable solution.

1
2
3
4
5
var xhr = new XMLHttpRequest();
xhr.open("GET", url, true);
// retrieve data unprocessed as a binary string
xhr.overrideMimeType("text/plain; charset=x-user-defined");
/* ... */

The XMLHttpRequest Level 2 Specification adds new responseType attributes which make sending and receiving binary data much easier.

1
2
3
4
5
6
7
8
var xhr = new XMLHttpRequest();
xhr.open("GET", url, true);
xhr.responseType = "arraybuffer"
xhr.onload = function(e) {
  var arraybuffer = xhr.response; // not responseText
  /* ... */
}
xhr.send();

For more examples check out the Sending and Receiving Binary Data page

Monitoring progress

XMLHttpRequest provides the ability to listen to various events that can occur while the request is being processed. This includes periodic progress notifications, error notifications, and so forth.

Support for DOM progress event monitoring of XMLHttpRequest transfers follows the Web API specification for progress events.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
var req = new XMLHttpRequest();
  
req.addEventListener("progress", updateProgress, false);
req.addEventListener("load", transferComplete, false);
req.addEventListener("error", transferFailed, false);
req.addEventListener("abort", transferCanceled, false);
  
req.open();
  
...
  
// progress on transfers from the server to the client (downloads)
function updateProgress(evt) {
  if (evt.lengthComputable) {
    var percentComplete = evt.loaded / evt.total;
    ...
  } else {
    // Unable to compute progress information since the total size is unknown
  }
}
  
function transferComplete(evt) {
  alert("The transfer is complete.");
}
  
function transferFailed(evt) {
  alert("An error occurred while transferring the file.");
}
  
function transferCanceled(evt) {
  alert("The transfer has been canceled by the user.");
}

Lines 3-6 add event listeners for the various events that are sent while performing a data transfer using XMLHttpRequest

Note: You need to add the event listeners before calling open() on the request.  Otherwise the progress events will not fire.

The progress event handler, specified by the updateProgress() function in this example, receives the total number of bytes to transfer as well as the number of bytes transferred so far in the event’s total and loaded fields.  However, if the lengthComputable field is false, the total length is not known and will be zero.

Progress events exist for both download and upload transfers. The download events are fired on the XMLHttpRequest object itself, as shown in the above sample. The upload events are fired on the XMLHttpRequest.upload object, as shown below:

1
2
3
4
5
6
7
8
var req = new XMLHttpRequest();
  
req.upload.addEventListener("progress", updateProgress, false);
req.upload.addEventListener("load", transferComplete, false);
req.upload.addEventListener("error", transferFailed, false);
req.upload.addEventListener("abort", transferCanceled, false);
  
req.open();
Note: Progress events are not available for the file: protocol.
Gecko 9.0 note

(Firefox 9.0 / Thunderbird 9.0 / SeaMonkey 2.6)

Starting in Gecko 9.0 (Firefox 9.0 / Thunderbird 9.0 / SeaMonkey 2.6), progress events can now be relied upon to come in for every chunk of data received, including the last chunk in cases in which the last packet is received and the connection closed before the progress event is fired. In this case, the progress event is automatically fired when the load event occurs for that packet. This lets you now reliably monitor progress by only watching the “progress” event.

Gecko 12.0 note

(Firefox 12.0 / Thunderbird 12.0 / SeaMonkey 2.9)

If your progress event is called with a responseType of “moz-blob”, the value of response is a Blob containing the data received so far.

One can also detect all three load-ending conditions (abort, load, or error) using the loadend event:

1
2
3
4
5
req.addEventListener("loadend", loadEnd, false);
  
function loadEnd(evt) {
  alert("The transfer finished (although we don't know if it succeeded or not).");
}

Note that there’s no way to be certain from the information received by the loadend event as to which condition caused the operation to terminate; however, you can use this to handle tasks that need to be performed in all end-of-transfer scenarios.

Cross-site XMLHttpRequest

Modern browsers support cross-site requests by implementing the web applications working group’s Access Control for Cross-Site Requests standard.  As long as the server is configured to allow requests from your web application’s origin, XMLHttpRequest will work.  Otherwise, an INVALID_ACCESS_ERR exception is thrown.

Bypassing the cache

Normally, XMLHttpRequest tries to retrieve content from the cache, if it’s available.  To bypass this, do the following:

1
2
3
4
var req = new XMLHttpRequest();
req.open('GET', url, false);
req.channel.loadFlags |= Components.interfaces.nsIRequest.LOAD_BYPASS_CACHE;
req.send(null);
Note: This approach will only work in Gecko-based software, as the channel attribute is Gecko-specific.

An alternate, cross-browser compatible approach is to append a timestamp to the URL, being sure to include a “?" or ”&“ as appropriate.  For example:

http://foo.com/bar.html

becomes

http://foo.com/bar.html?12345

and

http://foo.com/bar.html?foobar=baz

becomes

http://foo.com/bar.html?foobar=baz&12345

Since the local cache is indexed by URL, this causes every request to be unique, thereby bypassing the cache.

You can automatically adjust URLs using the following code:

1
2
3
var req = new XMLHttpRequest();
req.open("GET", url += ((/?/).test(url) ? "&" : "?") + (new Date()).getTime(), false);
req.send(null); 

Security

Firefox 3 note

Versions of Firefox prior to Firefox 3 allowed you to set the preference capability.policy.<policyname>.XMLHttpRequest.open</policyname> to allAccess to give specific sites cross-site access.  This is no longer supported.

Firefox 5 note

Versions of Firefox prior to Firefox 5 could use netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); to request cross-site access. This is no longer supported, even though it produces no warning and permission dialog is still presented.

The recommended way to enable cross-site scripting is to use the Access-Control-Allow-Origin HTTP header in the response to the XMLHttpRequest.

XMLHttpRequests being stopped

If you end up with an XMLHttpRequest having status=0 and statusText=null, it means that the request was not allowed to be performed. It was UNSENT. A likely cause for this is when the XMLHttpRequest origin (at the creation of the XMLHttpRequest) has changed when the XMLHttpRequest is then open(). This case can happen for example when one has an XMLHttpRequest that gets fired on an onunload event for a window: the XMLHttpRequest gets in fact created when the window to be closed is still there, and then the request is sent (ie open()) when this window has lost its focus and potentially different window has gained focus. The way to avoid this problem is to set a listener on the new window "activate” event that gets set when the old window has its “unload” event fired.

Downloading JSON and JavaScript from extensions

For security reasons, extensions should never use eval() to parse JSON or JavaScript code downloaded from the web.  See Downloading JSON and JavaScript in extensions for details.

Using XMLHttpRequest from JavaScript modules / XPCOM components

Instantiating XMLHttpRequest from a JavaScript module or an XPCOM component works a little differently; it can’t be instantiated using the XMLHttpRequest() constructor. The constructor is not defined inside components and the code results in an error. The best way to work around this is to use the XPCOM component constructor.

1
2
const XMLHttpRequest = Components.Constructor("@mozilla.org/xmlextras/xmlhttprequest;1");
var req = XMLHttpRequest();

Unfortunately in versions of Gecko prior to Gecko 16 there is a bug which can cause requests created this way to be cancelled for no reason.  If you need your code to work on Gecko 15 or earlier, you can get the XMLHttpRequest constructor from the hidden DOM window like so.

1
2
3
4
const { XMLHttpRequest } = Components.classes["@mozilla.org/appshell/appShellService;1"]
                                     .getService(Components.interfaces.nsIAppShellService)
                                     .hiddenDOMWindow;
var req = XMLHttpRequest();

See also

  1. MDC AJAX introduction
  2. HTTP access control
  3. How to check the security state of an XMLHTTPRequest over SSL
  4. XMLHttpRequest – REST and the Rich User Experience
  5. Microsoft documentation
  6. Apple developers’ reference
  7. “Using the XMLHttpRequest Object” (jibbering.com)
  8. The XMLHttpRequest Object: W3C Specification
  9. Web Progress Events specification
  10. Reading Ogg files with JavaScript (Chris Double)

https://developer.mozilla.org/en-US/docs/AJAX/Getting_Started

에서 참조

 

What’s AJAX?

AJAX stands for Asynchronous JavaScript and XML. In a nutshell, it is the use of the XMLHttpRequest object to communicate with server-side scripts. It can send as well as receive information in a variety of formats, including JSON, XML, HTML, and even text files. AJAX’s most appealing characteristic, however, is its “asynchronous” nature, which means it can do all of this without having to refresh the page. This lets you update portions of a page based upon user events.

The two features in question are that you can:

  • Make requests to the server without reloading the page
  • Receive and work with data from the server

Step 1 – How to make an HTTP request

In order to make an HTTP request to the server using JavaScript, you need an instance of a class that provides this functionality. Such a class was originally introduced in Internet Explorer as an ActiveX object, called XMLHTTP. Then Mozilla, Safari, and other browsers followed, implementing an XMLHttpRequest class that supports the methods and properties of Microsoft’s original ActiveX object.

As a result, in order to create a cross-browser instance (object) of the required class, you can do the following:

1
2
3
4
5
6
var httpRequest;
if (window.XMLHttpRequest) { // Mozilla, Safari, ...
    httpRequest = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE 8 and older
    httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}
Note: For illustration purposes, the above is a somewhat simplified version of the code to be used for creating an XMLHTTP instance. For a more real-life example, see step 3 of this article.

Next, you need to decide what you want to do after you receive the server response to your request. At this stage, you just need to tell the HTTP request object which JavaScript function will handle processing the response. This is done by setting the onreadystatechange property of the object to the name of the JavaScript function that should be called when the state of the request changes, like this:

httpRequest.onreadystatechange = nameOfTheFunction;

Note that there are no parentheses after the function name and no parameters passed, because you’re simply assigning a reference to the function, rather than actually calling it. Also, instead of giving a function name, you can use the JavaScript technique of defining functions on the fly (called “anonymous functions”) and define the actions that will process the response right away, like this:

1
2
3
httpRequest.onreadystatechange = function(){
    // process the server response
};

Next, after you’ve declared what will happen as soon as you receive the response, you need to actually make the request. You need to call the open() and send() methods of the HTTP request class, like this:

1
2
httpRequest.open('GET', 'http://www.example.org/some.file', true);
httpRequest.send(null);
  • The first parameter of the call to open() is the HTTP request method – GET, POST, HEAD or any other method you want to use and that is supported by your server. Keep the method capitalized as per the HTTP standard; otherwise some browsers (like Firefox) might not process the request. For more information on the possible HTTP request methods you can check the W3C specs.
  • The second parameter is the URL of the page you’re requesting. As a security feature, you cannot call pages on 3rd-party domains. Be sure to use the exact domain name on all of your pages or you will get a “permission denied” error when you call open(). A common pitfall is accessing your site by domain.tld, but attempting to call pages with www.domain.tld. If you really need to send a request to another domain, see HTTP access control.
  • The optional third parameter sets whether the request is asynchronous. If TRUE (the default), the execution of the JavaScript function will continue while the response of the server has not yet arrived. This is the A in AJAX.

The parameter to the send() method can be any data you want to send to the server if POST-ing the request. Form data should be sent in a format that the server can parse easily. This can be as a query string, like:

"name=value&anothername="+encodeURIComponent(myVar)+"&so=on"

or in several other formats, including JSON, SOAP, etc.

Note that if you want to POST data, you may have to set the MIME type of the request. For example, use the following line before calling send() for form data sent as a query string:

1
httpRequest.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');

Step 2 – Handling the server response

Remember that when you were sending the request, you provided the name of a JavaScript function that is designed to handle the response.

1
httpRequest.onreadystatechange = nameOfTheFunction;

Let’s see what this function should do. First, the function needs to check for the state of the request. If the state has the value of 4, that means that the full server response has been received and it’s OK for you to continue processing it.

1
2
3
4
5
if (httpRequest.readyState === 4) {
    // everything is good, the response is received
} else {
    // still not ready
}

The full list of the readyState values is as follows:

  • 0 (uninitialized)
  • 1 (loading)
  • 2 (loaded)
  • 3 (interactive)
  • 4 (complete)

(Source)

The next thing to check is the response code of the HTTP server response. All the possible codes are listed on the W3C site. In the following example, we differentiate between a successful or unsuccessful AJAX call by checking for a  200 OK response code.

1
2
3
4
5
6
7
if (httpRequest.status === 200) {
    // perfect!
} else {
    // there was a problem with the request,
    // for example the response may contain a 404 (Not Found)
    // or 500 (Internal Server Error) response code
}

Now after you’ve checked the state of the request and the HTTP status code of the response, it’s up to you to do whatever you want with the data the server has sent to you. You have two options to access that data:

  • httpRequest.responseText – returns the server response as a string of text
  • httpRequest.responseXML – returns the response as an XMLDocument object you can traverse using the JavaScript DOM functions

Note that the steps above are only valid if you used an asynchronous request (third parameter of open() was set to true). If you used an synchronous request you don’t need to specify a function, you can access the data return by the server right after calling send(), because the script will stop and wait for the server answer.

Step 3 – A Simple Example

Let’s put it all together and do a simple HTTP request. Our JavaScript will request an HTML document, test.html, which contains the text “I’m a test.” and then we’ll alert() the contents of the test.html file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<span id="ajaxButton" style="cursor: pointer; text-decoration: underline">
  Make a request
</span>
<script type="text/javascript">
(function() {
  var httpRequest;
  document.getElementById("ajaxButton").onclick = function() { makeRequest('test.html'); };
  
  function makeRequest(url) {
    if (window.XMLHttpRequest) { // Mozilla, Safari, ...
      httpRequest = new XMLHttpRequest();
    } else if (window.ActiveXObject) { // IE
      try {
        httpRequest = new ActiveXObject("Msxml2.XMLHTTP");
     
      catch (e) {
        try {
          httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
       
        catch (e) {}
      }
    }
  
    if (!httpRequest) {
      alert('Giving up 🙁 Cannot create an XMLHTTP instance');
      return false;
    }
    httpRequest.onreadystatechange = alertContents;
    httpRequest.open('GET', url);
    httpRequest.send();
  }
  
  function alertContents() {
    if (httpRequest.readyState === 4) {
      if (httpRequest.status === 200) {
        alert(httpRequest.responseText);
      } else {
        alert('There was a problem with the request.');
      }
    }
  }
})();
</script>

In this example:

  • The user clicks the link “Make a request” in the browser;
  • The event handler calls the makeRequest() function with a parameter – the name test.html of an HTML file in the same directory;
  • The request is made and then (onreadystatechange) the execution is passed to alertContents();
  • alertContents() checks if the response was received and it’s an OK and then alert()s the contents of the test.html file.
Note: If you’re sending a request to a piece of code that will return XML, rather than to a static XML file, you must set some response headers if your page is to work in Internet Explorer in addition to Mozilla. If you do not set header Content-Type: application/xml, IE will throw a JavaScript error, “Object Expected”, after the line where you try to access an XML element. 
Note 2: If you do not set header Cache-Control: no-cache the browser will cache the response and never re-submit the request, making debugging “challenging.” You can also append an always-diferent aditional GET parameter, like the timestamp or a random number (see bypassing the cache)
Note 3: If the httpRequest variable is used globally, competing functions calling makeRequest() may overwrite each other, causing a race condition. Declaring the httpRequest variable local to a closure containing the AJAX functions prevents the race condition.
Note 4: In the event of a communication error (such as the webserver going down), an exception will be thrown in the onreadystatechange method when attempting to access the status field. Make sure that you wrap your if…then statement in a try…catch. (See: bug 238559).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
function alertContents(httpRequest) {
  try {
    if (httpRequest.readyState === 4) {
      if (httpRequest.status === 200) {
        alert(httpRequest.responseText);
      } else {
        alert('There was a problem with the request.');
      }
    }
  }
  catch( e ) {
    alert('Caught Exception: ' + e.description);
  }
}

Step 4 – Working with the XML response

In the previous example, after the response to the HTTP request was received we used the responseText property of the request object, which contained the contents of the test.html file. Now let’s try the responseXML property.

First off, let’s create a valid XML document that we’ll request later on. The document (test.xml) contains the following:

1
2
3
4
<?xml version="1.0" ?>
<root>
    I'm a test.
</root>

In the script we only need to change the request line to:

1
2
3
...
onclick="makeRequest('test.xml')">
...

Then in alertContents(), we need to replace the line alert(httpRequest.responseText); with:

1
2
3
var xmldoc = httpRequest.responseXML;
var root_node = xmldoc.getElementsByTagName('root').item(0);
alert(root_node.firstChild.data);

This code takes the XMLDocument object given by responseXML and uses DOM methods to access some of the data contained in the XML document. You can see the test.xml here and the updated test script here.

Step 5 – Working with data

Finally, let’s send some data to the server and receive a response. Our JavaScript will request a dynamic page this time, test.php, which will take the data we send and return a “computed” string – “Hello, [user data]!” – which we’ll alert().

First we’ll add a text box to our HTML so the user can enter their name:

1
2
3
4
5
6
<label>Your name: 
  <input type="text" id="ajaxTextbox" />
</label>
<span id="ajaxButton" style="cursor: pointer; text-decoration: underline">
  Make a request
</span>

We’ll also add a line to our event handler to get the user’s data from the text box and send it to the makeRequest() function along with the URL of our server-side script:

1
2
3
4
  document.getElementById("ajaxButton").onclick = function() { 
      var userName = document.getElementById("ajaxTextbox").value;
      makeRequest('test.php',userName); 
  };

We need to modify makeRequest() to accept the user data and pass it along to the server. We’ll change the request method from GET to POST, and include our data as a parameter in the call to httpRequest.send():

1
2
3
4
5
6
7
8
9
  function makeRequest(url, userName) {
  
    ...
  
    httpRequest.onreadystatechange = alertContents;
    httpRequest.open('POST', url);
    httpRequest.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    httpRequest.send('userName=' + encodeURIComponent(userName));
  }

The function alertContents() can be written the same way it was in Step 3 to alert our computed string, if that’s all the server returns. However, let’s say the server is going to return both the computed string and the original user data. So if our user typed “Jane” in the text box, the server’s response would look like this:

{"userData":"Jane","computedString":"Hi, Jane!"}

To use this data within alertContents(), we can’t just alert the responseText, we have to parse it and alert computedString, the property we want:

1
2
3
4
5
6
7
8
9
function alertContents() {
    if (httpRequest.readyState === 4) {
      if (httpRequest.status === 200) {
        var response = JSON.parse(httpRequest.responseText);
        alert(response.computedString);
    } else {
      alert('There was a problem with the request.');
    }
}

Send a Request To a Server

To send a request to a server, we use the open() and send() methods of the XMLHttpRequest object:

xmlhttp.open(“GET”,“ajax_info.txt”,true);
xmlhttp.send();

Method Description open(method,url,async) Specifies the type of request, the URL, and if the request should be handled asynchronously or not.

method: the type of request: GET or POST
url: the location of the file on the server
async: true (asynchronous) or false (synchronous) send(string) Sends the request off to the server.

string: Only used for POST requests


GET or POST?

GET is simpler and faster than POST, and can be used in most cases.

However, always use POST requests when:

  • A cached file is not an option (update a file or database on the server)
  • Sending a large amount of data to the server (POST has no size limitations)
  • Sending user input (which can contain unknown characters), POST is more robust and secure than GET

http://msdn.microsoft.com/en-us/library/ms531424(v=vs.85).aspx

에서 참조

userData Behavior

30 out of 50 rated this helpful Rate this topic

Enables the object to persist data in user data.

Syntax

XML<Prefix: CustomTag ID=sID STYLE="behavior:url('#default#userData')" /> HTML <ELEMENT STYLE="behavior:url('#default#userData')" ID=sID> Scripting object .style.behavior = "url('#default#userData')" object .addBehavior ("#default#userData")

Possible Values

Prefix Prefix that associates the CustomTag with an XML namespace. This prefix is set using the XMLNS attribute of the HTML tag. CustomTag User-defined tag. sIDString that specifies a unique identifier for the object.

Members Table

The following table lists the members exposed by the userData object.

Attributes/Properties
PropertyDescriptionexpires Sets or retrieves the expiration date of data persisted with the userData behavior. XMLDocumentRetrieves a reference to the XML
Methods
MethodDescriptiongetAttribute Retrieves the value of the specified attribute. load Loads an object participating in userData persistence from a UserData store. removeAttribute Removes the specified attribute from the object. save Saves an object participating in userData persistence to a UserData store. setAttributeSets the value of the specified attribute.

Remarks

security note Security Alert  For security reasons, a UserData store is available only in the same directory and with the same protocol used to persist the store.
security note Security Alert  Using this behavior incorrectly can compromise the security of your application. Data in a UserData store is not encrypted and therefore not secure. Any application that has access to the drive where UserData is saved has access to the data. Therefore, it is recommended that you not persist sensitive data like credit card numbers. For more information, see Security Considerations: DHTML and Default Behaviors.

The userData behavior persists information across sessions by writing to a UserData store. This provides a data structure that is more dynamic and has a greater capacity than cookies. The capacity of the UserData store depends on the security zone of the domain. The following table shows the maximum amount of UserData storage that is available for an individual document and also the total available for an entire domain, based on the security zone.

Security ZoneDocument Limit (KB)Domain Limit (KB)Local Machine1281024Intranet51210240Trusted Sites1281024Internet1281024Restricted64640

See URLACTION_HTML_USERDATA_SAVE for information on how the userData behavior is regulated. See About URL Security Zones Templates for further information on the default URL policy settings for each of the five security zone templates.

The userData behavior persists data across sessions, using one UserData store for each object. The UserData store is persisted in the cache using the save and load methods. Once the UserData store has been saved, it can be reloaded even if Windows Internet Explorer has been closed and reopened.

Setting the userData behavior class on the html, head, title, or style object causes an error when the save or load method is called.

The required style can be set inline or in the document header, as follows:

Copy
   <STYLE>

      .storeuserData {behavior:url(#default#userData);}

   </STYLE>

An ID is optional for userData, but including one improves performance.

The userData behavior is available as of Microsoft Internet Explorer 5, in the Microsoft Win32 and Unix platforms.

Examples

This example uses the userData behavior to preserve information in a UserData Store.

Copy
<html>



<head>

<style type="text/css">

.storeuserData {

    behavior: url(#default#userData);

}

</style>



function fnSaveInput(){

   var oPersist=oPersistForm.oPersistInput;

   oPersist.setAttribute("sPersist",oPersist.value);

   oPersist.save("oXMLBranch");

}

function fnLoadInput(){

   var oPersist=oPersistForm.oPersistInput;

   oPersist.load("oXMLBranch");

   oPersist.value=oPersist.getAttribute("sPersist");

}



</head>



<body>



<form id="oPersistForm">

    <input class="storeuserData" type="text" id="oPersistInput">

    <input type="button" value="Load" onclick="fnLoadInput()">

    <input type="button" value="Save" onclick="fnSaveInput()">

</form>



</body>



</html>

Code example: http://samples.msdn.microsoft.com/workshop/samples/author/persistence/userData_1.htm

The following example uses the userData behavior in a custom tag to preserve information in a UserData Store.

Copy
<html xmlns:sdk="">



<head>

<style type="text/css">

sdk:cacher {

    behavior: url(#default#userData);

}

</style>



function fnSaveInput(){

   cachetag.setAttribute("sPersist",txt1.value);

   cachetag.save("cache");

}

function fnLoadInput(){

   cachetag.load("cache");

   cachetag.value=cachetag.getAttribute("sPersist");

}



</head>



<body>



<sdk:cacher id="cachetag"></sdk:cacher>

<input type="button" value="Load" onclick="fnLoadInput()">

<input type="button" value="Save" onclick="fnSaveInput()">

<input type="text" id="txt1" value="some value">



</body>



</html>

Introduction to Persistence

13 out of 27 rated this helpful Rate this topic

Note  As of December 2011, this topic has been archived and is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Windows Internet Explorer, see Internet Explorer Developer Center.

Persistence enables authors to specify an object to persist on the client during the current and later sessions using Dynamic HTML (DHTML) behaviors. Persistence allows Microsoft Internet Explorer 5 and later to retain Web page information, styles, variables, and state. For example, a collapsible list of links within a table of contents can remain expanded to the user’s choice upon leaving and later returning to the page. Or, a search engine query form can retain the last-used search string.

Persistence is implemented as a behavior. The new persistence behaviors include:

  • saveFavorite—persists page state and information when the web page is saved as a favorite.
  • saveHistory—persists page state and information within the current session’s memory.
  • saveSnapshot—persists page state and information directly in the page when users save the Web page to their hard disk.
  • userData—persists page state and information within an XML store, a hierarchical data structure.

Persistence creates new opportunities for the author. Information that persists beyond a single page without support from the server, or within the finite scope of cookies, can increase the speed of navigation and content authoring.

These behaviors can be used to preserve information in the browser’s history, in favorites, in an XML store, or directly within a Web page saved to disk. When a user returns to a persisted page, the state of the page can be restored. By allowing information to safely reside on the client, fewer server transactions are required. Custom start pages and Web applications prosper because information can continue to exist without the paternal support of the server, or repeated server queries. A Web page can remain interactive to a degree, after the connection with the host has been severed, by persisting required information on the client.

Benefits

Use of persistence in Internet Explorer 5 breaks away from the tradition of using cookies and session files to store information. The Microsoft model for client/server relationships using persistence and Internet Explorer 5 is pragmatic; it maintains the same-domain security policy associated with cookies while increasing storage and management capabilities.

Server solutions Persistence solutions Start pages Custom start pages often rely on cookies and server-side databases to preserve client-specific information. Storing information such as client capabilities, favorite styles, and favorite content requires additional queries to the server to retrieve the information. This results in increased download time for the client and increased processing demands on the server.Persistence via Dynamic HTML (DHTML) behaviors allows a page author to store information on the client. This reduces the need to query a server database for client-specific information and increases the overall performance of the page. Persistence stores the data hierarchically, making it more accessible.Web appsWeb-based applications have remained tied to the server for the back-end strength and processing power they require. A Web site that includes a basic form to be sent in e-mail uses a server to handle the request, or a script to process any e-mail beyond a conventional note.A persistent Web page can be saved with its form values intact, making it easier to transfer or preserve an entire document. Persistence introduces a new paradigm for Web applications by giving authors the ability to produce complex Web-based applications that take advantage of the client’s processing power.FormsAdvanced search engines and information entry and retrieval forms often rely on session variables and files to preserve information across Web pages. The server must send and store the same information with each new visit to the Web page, taxing the Web server and the Internet line.While there is some information that should remain on the server, the rest can be stored on the client. Client-side scripting within each Web page can perform the necessary validation routines, leaving the server to higher-level security concerns. Since persisted information maintains a similar same-domain security structure as cookies, the client can be assured that rogue Web sites will not glean such information from their computers.

Using Persistence

Persistence behaviors require certain conditions before they can be used. A meta tag directs the browser that the page is persistent. Persistent elements are identified with a CLASS and an ID property. The onsave and onload event handlers can be defined for nondefault handling.

Behavior Description saveFavoritePersists an object across sessions when the page has been saved as a favorite.

The getAttribute and setAttribute methods are used to store information on a persistent object. The onload and onsave event handlers can be used to call the methods.

The saveFavorite behavior is ideal for persisting user-selected styles within a favorite or shortcut. The persisted information is stored within each favorite, allowing multiple favorites with different persisted information to exist.

saveHistoryPersists an object during the current session.

The getAttribute and setAttribute methods can be used to store information on objects participating in persistence. The onload and onsave event handlers can be used to call the methods.

The saveHistory behavior is ideal for storing information only while the browser is open, such as page state for collapsible content, or dynamic styles.

saveSnapshotPersists an object across sessions when a page has been saved as Web Page, HTML Only.

Form elements persist automatically. Script blocks designated to persist can contain only variables. Script objects and comments are removed. Qualifying variables from external sources on persisting script blocks are inserted.

The saveSnapshot behavior is ideal for persisting Web application information to the client’s disk for later retrieval.

userDataPersists an object across sessions in a UserData store (an arbitrary storage facility) when the object has been explicitly saved.

Form elements, styles, and dynamic values can be persisted using the getAttribute and setAttribute methods, and then explicitly saved using the load and save methods.

The userData behavior is ideal for persisting information across sessions and storing information in a hierarchical structure. It provides a good alternative to using cookies. The capacity of the userData store is 64 KB per page, with a limit of 640 KB per domain, for restricted sites. For security reasons, a userData store is available only in the same directory and with the same protocol used to persist the store.

Security Warning:  Using these behavior incorrectly can compromise the security of your application. The saveFavorite, saveSnapshot, and userData behaviors persist data as plain text in a saved Web page. Text is not encrypted and therefore not secure. Any application that has access to the drive where the page is saved also has access to the data and can tamper with it. Therefore, it is recommended that you not persist sensitive data like credit card numbers. For more information, see Security Considerations: DHTML and Default Behaviors.

An ID is not required for the saveFavorite and saveHistory behaviors, but is recommended for performance. The style element also can be set inline on a persistent object.

Example Uses of Persistence

The following examples show how to use behaviors to implement persistence.

The following examples shows the saveFavorite behavior.

<!-- Tell the browser the page is persistent-->
<META NAME="save" CONTENT="favorite">
<!-- Define the class for the persistent object-->
<STYLE>
    .saveFavorite {behavior:url(#default#savefavorite);}
</STYLE>

// Record information to the persistent object as an attribute.
function fnSave(){
   oPersistInput.setAttribute("sPersistAttr",oPersistInput.value);
}
// Retrieve information from a persistent object.
function fnLoad(){
   oPersistInput.value=oPersistInput.getAttribute("sPersistAttr");
}

:
<!-- The CLASS enables the object to persist, the event handlers 
     fire the scripted functions.-->
<INPUT
   TYPE="text"
   CLASS="saveFavorite"
   ID="oPersistInput"
   onload="fnLoad()"
   onsave="fnSave()"
>

Click to view sample.

The following example shows the saveHistory behavior.

<!-- Tell the browser the page is persistent-->
<META NAME="save" CONTENT="history">
<!-- Define the class for the persistent object-->
<STYLE>
    .saveHistory {behavior:url(#default#savehistory);}
</STYLE>
:
<!-- The default behavior is to persist form elements.
   When the saveHistory behavior is defined, form elements
   will not persist unless they have a class.
-->
This persists:
<INPUT TYPE="text" CLASS="saveHistory" ID="oPersistInput">
This does not persist:
<INPUT TYPE="text">

Click to view sample.

The following example shows the saveSnapshot behavior.

<!-- Tell the browser the page is persistent-->
<META NAME="save" CONTENT="snapshot">
<!-- Define the class for the persistent object-->
<STYLE>
    .saveSnapshot {behavior:url(#default#savesnapshot);}
</STYLE>
:
<!-- When the page is saved, the information entered in the
     persistent form element will be inserted as the value
     within the HTML file.-->
<INPUT TYPE=text CLASS=saveSnapshot ID=oPersistInput>
:

Click to view sample.

The following example shows the userData behavior.

<!-- Define the class for the persistent object-->
<STYLE>
    .userData {behavior:url(#default#userdata);}
</STYLE>

    function fnSaveInput(){
   
// Persistent information is stored as an attribute
// on the persistent object, and saved within a
// UserData store.
      var oPersist=oPersistForm.oPersistInput;
      oPersist.setAttribute("sPersist",oPersist.value);
      oPersist.save("oXMLBranch");
	  
   }
    function fnLoadInput(){

// Persistent information is loaded from a UserData store
// and the value is restored from the persisted attribute.

      var oPersist=oPersistForm.oPersistInput;
      oPersist.load("oXMLBranch");
      oPersistInput.value=oPersistInput.getAttribute("sPersist");
   }

:
<FORM ID="oPersistForm">
<INPUT class=userData type=text id=oPersistInput>
<INPUT type=button value="Load" onclick="fnLoadInput()">
<INPUT type=button value="Save" onclick="fnSaveInput()">
</FORM>

Click to view sample.

Persisting Content in XML

The XMLDocument property allows the saveFavorite, saveHistory, and userData behaviors to access the XML Document Object Model (DOM). Using the XML DOM, persistent objects have access to the objects, properties, and methods that allow the author to build hierarchical data structures.

var oXMLDocument=oPersistText.XMLDocument;
var oNode=oXMLDocument.createNode("element","MyElement", "");
oNode.nodeValue="The value of MyElement";
oXMLDocument.documentNode.insertNode("MyElement");

In XML, this would yield:

<MyElement>The value of MyElement</MyElement>

Persistence How-Tos

Persistence introduces a broad expanse of possibilities. The following how-to articles cover some of the more interesting, albeit easy-to-employ, uses of persistence.

Related topics

Dynamic HTML (DHTML) Articles Introduction to DHTML Behaviors Client Capabilities Default Behaviors Reference

Send comments about this topic to Microsoft

Build date: 10/26/2012