«

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="referencingExternalLibrariesB.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("otherScript");
*/
function include(scriptSrc) {
var headElement = document.getElementsByTagName("head")[0];
var scriptElement = document.createElement("script");
scriptElement.setAttribute("type", "text/javascript");
scriptElement.setAttribute("src", scriptSrc);
headElement.appendChild(scriptElement);
}

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

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.

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

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

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
>>>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

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.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

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 "Dynamically 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.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

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.