http://help.dottoro.com/ljqlhagh.php
에서 참조
Syntax:
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:
http://help.dottoro.com/ljqlhagh.php
에서 참조
Syntax:
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:
definition of ‘data island’ ( wikipedia )
A data island is a data store, such as on a PDA or other computing device, that has non-existent or limited external connectivity.
This limits the ability of the user to synchronize with or copy the data to other devices. Though new data can be added to the system, the ability to move that data elsewhere is impractical or impossible.
Data islands, in general, contain a very huge set of data relative to its small physical space that it occupies. The connectivity here does not necessarily imply a hardware interface. For example, it may be a result of poorly written system interface software.
A data island is a subset of entities that are connected to each other via relationships, but that are independent of other entities within the same data store.
definition of ‘data island’ ( wikipedia )
A data island is a data store, such as on a PDA or other computing device, that has non-existent or limited external connectivity.
This limits the ability of the user to synchronize with or copy the data to other devices. Though new data can be added to the system, the ability to move that data elsewhere is impractical or impossible.
Data islands, in general, contain a very huge set of data relative to its small physical space that it occupies. The connectivity here does not necessarily imply a hardware interface. For example, it may be a result of poorly written system interface software.
A data island is a subset of entities that are connected to each other via relationships, but that are independent of other entities within the same data store.
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.