External Scripts
March 15, 1999
The <SCRIPT> tag supports another attribute, SRC, which
lets you point to an external file containing
script code. Typically this external file contains JavaScript
although it needn't necessarily. Unfortunately, combining
the LANGUAGE and SRC attributes can be a bit confusing.
Microsoft Internet Explorer 4 and 5 supports the following:
<script language="JavaScript1.2" src="myfuncs.js">
But Netscape Navigator does not recognize both attributes
when used simultaneously; rather, Netscape will include
the external file references by SRC but will not heed the
language requirement. Thus, the above tag will pull in
myfuncs.js even if the browser is Navigator 3.0 and
doesn't support JavaScript 1.2. There is a little trick
to work around this problem -- let's say that you want
to include the functions contained within myfuncs.js
but only if the browser is at least version 4:
<script language="JavaScript1.2">
document.write
("<script src='myfuncs.js'><\/script>");
</script>
In the above trick we manage to lure HTML into behaving
almost like a logic processing programming language;
the outer <SCRIPT> tag allows only JavaScript 1.2-capable
browsers from executing the inner code line. The
inner code uses the document.write() method of
JavaScript to output another HTML tag to the page, which
happens to be another <SCRIPT> tag, which itself
uses the SRC attribute to pull the functions into the page.
Clever.
While the above trick isn't necessary with MSIE, it
will work there, too, making this a cross-browser compatible
technique.
In any case, your external script can contain any code you
like, but it usually contains functions. Functions
provide the modularity we seek in a programming architecture.
The format of the .js file is simply the naked
script with no HTML tags present. For example, consider
this page made up of two files: one is the HTML source
and the other is the JavaScript source.
eshop.html
<html>
<head>
<title>E-Shop</title>
<script src="eshop_calcs.js">
</script>
</head>
<body>
...etc...
</body></html>
eshop_calcs.js
function calcShipping(weight,state)
{ ... }
function calcTax(price,state)
{ ... }
Now you can see why external files allow for the possibility
of creating portable functions. Imagine that you
authored the calcShipping() function. Suppose it
only required two incoming parameters, shipment weight
and the destination state. The function itself then did
all the dirty work -- translating the state abbreviation
into a shipping zone and calculating the rate based on
some representation of the shipping rate chart which you've
built into the function. Once done the function simply
returns a number reflecting the cost. As long as this function
is coded portably; that is, relies only on internal local
variables to do the work, you could distribute this function
to anyone who wanted the ability to calculate shipping rates.
In fact, others wouldn't even need to copy the function
from you. They could simply link to it on your server,
should you be in such a generous mood:
<script src=
"http://www.niceguys.com/shopping/calcShipping.js">
Such a setup would be highly modular and portable -- if you
had to change the rate table, you simply modify
this function and every site which links to it will
automatically reflect the new rates. Even if you are not ready
to distribute your modular functions globally, this
type of portability is useful even within your own site, since
any page on your site can easily access common functions.
And changes to these functions are immediately reflected
on every page which uses them.
From a people perspective, the JavaScript god of your team
can play with calcShipping() all day without
needing to see any of the HTML -- and vice versa for your
HTML monkeys.
While the SRC attribute goes a long way to helping segregate
programming language from markup tags, it is no
panacea. There remains one large, sticky problem, and those
are event handlers.
Embedding Code
Creating Portable and Modular Client-Side Scripts
Ugly Grafted Event Handlers
|
