External Javascript
You will have noticed from your inspection of real-world AJAX pages that the sort of architecture we're using, where all the scripts are written into the HTML page, is almost nowhere to be found.
Most Javascript code chunks live in external files -- plain-text documents with the extension .js.
You can connect your HTML page to an external document via a blank <script></script> container, where the initial tag contains an src attribute. Here's an example, which you'll see verbatim in many of our projects this term:
<script type="text/javascript" src="javascript/xmlLoader.js"></script>
You might think of this structure as something like an include statement in programming languages. It reaches out to a document called xmlLoader.js, located in a directory called javascript, which is within the same directory as the page. Anything defined in that external Javascript file becomes part of the page, just as if it had been typed into an internal <script></script> container of the type we've been using up to now.
This means any variables and methods defined in the external script become active for the page that includes them. In the case of our XML loader, including the external script allows us to call a function called loadXML(what), which accepts the name of an XML file as its argument. As you might guess, this function is almost entirely identical to the XML-loading code we learned to use earlier in the course -- except for the fact that the instructions are now contained in a function body, allowing them to be called from multiple Web pages.
If you open the external Javascript (.js) page in a text editor, you'll also notice another significant difference from internal Javascript: THERE ARE NO SCRIPT CONTAINERS in the external file. External Javascript documents are designed to be injected (in effect) into a blank script container on the page that includes them. Strictly speaking, the mechanism is not the same as an innerHTML replacement, but the effect is nearly identical, and you might find the analogy useful.
Now let's turn back to the Web page for a moment. Notice that you are not required to put all Javascript assets into external script files. It's perfectly acceptable to have more than one <script></script> container in an HTML document. In most cases, we'll want to place a container that includes an external script ahead of any internal script that depends on it. If we have an internal page script that does things with an XML document, we would put the blank script container that includes our XML loader ahead of the internal script.
So, if mixed usage is allowed, when should you externalize Javascript, and when should you stick with the internal approach?
Industrial-duty scripts, which can run to hundreds and thousands of lines, need to be deployed in external files. It's simply too difficult to edit them if they're mixed into Web pages. More important, though, these scripts are almost always designed to exist as independent components, flexibly available to multiple pages.
However, if you need to do something with Javascript on one and only one page, there is no reason to use an external file, unless it helps manage heavily complicated code.
It's also important (though not strictly necessary) to install external script pages in their own directory. In our example, we call this directory javascript, but you can use any name you like. This directory can be located anywhere in your Internet domain.
|