Create references to external scipt files from within an external script file

[Mellow Crow]

Just discovered this technique. Is this old hat? Would there be any
disadvantage to doing this?

In your external .js file:

/*
Summary: includes external scripts in this external script
so that you don't have to reference them within the (x)html
document
files.
Remarks:
In effect this inserts something like
<script type="text/javascript"
src="referencin gExternalLibrar iesB.js"></script>
into the html document.
Param:
scriptUrl (String)
an absolute or relative url.
Usage: In your external scripts, at the top of your documents,
include("file:///C:/temp/myScript.js");
include("otherS cript");
*/
function include(scriptS rc) {
var headElement = document.getEle mentsByTagName( "head")[0];
var scriptElement = document.create Element("script ");
scriptElement.s etAttribute("ty pe", "text/javascript");
scriptElement.s etAttribute("sr c", scriptSrc);
headElement.app endChild(script Element);
}

Full example online:
<http://www.softmake.com.au/webScript...alLibraries.ht
ml>

[Richard Cornford]

Mellow Crow wrote:

Just discovered this technique. Is this old hat?
It is not old hat as such because the number of browsers that fully
support the technique only recently increased to the point where it
could be considered viable in an Internet context. It has been known,
and experimented with, for some considerable time.
Would there be any
disadvantage to doing this?

<snip>

Yes, you will be excluding some browsers from being able to use the
script without necessarily having a good reason for doing so.

Richard.

[Mellow Crow]

Richard, both of your points are helpful, thanks.

Richard Cornford wrote:

Mellow Crow wrote:

Just discovered this technique. Is this old hat?

It is not old hat as such because the number of browsers that fully
support the technique only recently increased to the point where it
could be considered viable in an Internet context. It has been known,
and experimented with, for some considerable time.

Yes. It's a W3C/standards/"modern" technique so it's new in that sense.

Would there be any
disadvantage to doing this?

<snip>

Yes, you will be excluding some browsers from being able to use the
script without necessarily having a good reason for doing so.

Yes. That's true. Raises the fundamental issue of whether you should design
for graceful degradation or simply ignore older browsers. I'm sure this has
been thrashed out elsewhere.

May have found a second potential disadvantage.
When testing your page from served local web server (not file system) AND
you use the technique of this thread AND
you are referencing a script file from outside the root of your domain,
using the file system (eg file:///C:/Data/...)
THEN
You get errors :(

[Thomas 'PointedEars' Lahn]

Mellow Crow wrote:

May have found a second potential disadvantage.
When testing your page from served local web server (not file system) AND
you use the technique of this thread AND
you are referencing a script file from outside the root of your domain,
using the file system (eg file:///C:/Data/...)
THEN
You get errors :(

Works as designed.
PointedEars

[Randy Webb]

Mellow Crow said the following on 11/4/2005 6:27 AM:

Richard, both of your points are helpful, thanks.

Richard Cornford wrote:

Mellow Crow wrote:

Just discovered this technique. Is this old hat?

It is not old hat as such because the number of browsers that fully
support the technique only recently increased to the point where it
could be considered viable in an Internet context. It has been known,
and experimented with, for some considerable time.

Yes. It's a W3C/standards/"modern" technique so it's new in that sense.

Would there be any
disadvanta ge to doing this?

<snip>

Yes, you will be excluding some browsers from being able to use the
script without necessarily having a good reason for doing so.

Yes. That's true. Raises the fundamental issue of whether you should design
for graceful degradation or simply ignore older browsers. I'm sure this has
been thrashed out elsewhere.

May have found a second potential disadvantage.
When testing your page from served local web server (not file system) AND
you use the technique of this thread AND
you are referencing a script file from outside the root of your domain,
using the file system (eg file:///C:/Data/...)
THEN
You get errors :(

Security errors is what they should be. It is because you are on the
server localhost (or similar) and you are pulling data from the HD. No
different than the page being on www.sampleDomain.com and trying to get
data from your HD. The solution? Put your script files on the "server"
and address them that way.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Mellow Crow said the following on 11/3/2005 8:21 PM:

Just discovered this technique. Is this old hat? Would there be any
disadvantage to doing this?
Define "old hat" and the age it requires to be considered old hat. As
for the technique of loading JS files on the fly, it is not new. Nowhere
close to new.

<URL:
http://groups.google.com/group/comp....scoring%3Dd%26

Search the archives for "Dynamicall y loading a .js file" and you will
find the above thread in case the URL gets broken. That article is 2 1/2
years old and I was not the first one to start using that method.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Richard Cornford]

Mellow Crow wrote:

Richard Cornford wrote:

Mellow Crow wrote:

Just discovered this technique. Is this old hat?
It is not old hat as such because the number of browsers that
fully support the technique only recently increased to the
point where it could be considered viable in an Internet
context. It has been known, and experimented with, for some
considerable time.

Yes. It's a W3C/standards/"modern" technique so it's new in that
sense.

Browser scripting is about ten years old, and the oldest W3C DOM
standards about 6 years old. How modern is modern?

Would there be any
disadvantage to doing this?

<snip>

Yes, you will be excluding some browsers from being able to
use the script without necessarily having a good reason for
doing so.

Yes. That's true. Raises the fundamental issue of whether
you should design for graceful degradation or simply ignore
older browsers.

Those are not the applicable either/ors in this situation. The most
modern, dynamic, DOM standard and capable web browser can have scripting
turned off. So designing for clean degradation should be necessary in
all open public contexts in order to accommodate even modern browsers in
certain (legitimate and possible) configurations.

But browsers are increasingly appearing on small mobile devices. These
browsers are modern (and more or less standards compliant), but not
necessarily nearly as dynamic as desktop browsers. It may be, and has
been, argued that the need for clean degradation in Internet scripts is
currently increasing as a result.
I'm sure this has been thrashed out elsewhere.

<snip>

It has, but there is no good reason not to state a case and see what
happens. Designing for clean-degradation is very important to the
subject of browser scripting with javascript.

Richard.