how to call external .js file from another .js file

S

shotokan99

hi,

usually if we call external js file by declaring them in our html page
head section:

<head>
..
..
..
<script language="JavaScript" src="j1.js"></script>
<script language="JavaScript" src="j1_ext.js"></script>
</head>

my question is...is it possible to declare j1_ext.js from j1.js?
eliminating j1_ext.js from <head ..> section declaration.

<head>
..
..
..
<script language="JavaScript" src="j1.js"></script>
</head>

tnx
 
R

RobG

hi,

usually if we call external js file by declaring them in our html page
head section:

<head>
.
.
.
<script language="JavaScript" src="j1.js"></script>
<script language="JavaScript" src="j1_ext.js"></script>
</head>

my question is...is it possible to declare j1_ext.js from j1.js?
eliminating j1_ext.js from <head ..> section declaration.

Yes, the simplest method would be to use something like:

<script>
var srcArray = [
'src1.js',
'src2.js',
...
];
document.write(
'<script src="' +
srcArray.join('"><\/script><script src="') +
'"><\/script>');
</script>

But you are probably better off to concatenate all your scripts into
one file at the server.
 
T

Thomas 'PointedEars' Lahn

shotokan99 said:
usually if we call external js file

These are not files that are called, but script resources which content
is included as if it was the content of the including `script' element.
by declaring them in our html page

They are not declared, they are hypertext-referenced (or "included"). A
declaration in (X)HTML begins with "<!" and ends with ">". You may know the
DOCTYPE declaration which is vital for avoiding the Quirks/Compatibility
Mode of current Web browsers.
head section:

It is the `head' element of an (X)HTML document.
<head>
.
.
.
<script language="JavaScript" src="j1.js"></script>
<script language="JavaScript" src="j1_ext.js"></script>

The `language' attribute is deprecated long since (and unnecessary), the
`type' attribute is required:

</head>

my question is...is it possible to declare j1_ext.js from j1.js?

It is not possible to load a script resource A from another script resource
B that requires A; at least not reliably. That said, trying to load any
script resource with client-side scripting is inherently unreliable, and
there is hardly a real need for that.
eliminating j1_ext.js from <head ..> section declaration.

That is not a declaration either.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Randy said:
Johannes Baagoe said the following on 9/5/2007 5:20 PM:

I shouldn't have said the type attribute was obsolete, it isn't. What
is obsolete is the only acceptable value for the attribute.
text/javascript was obsoleted the minute it was standardized.

Wrong. RFC4329, which you are you are referring to is *not* on the IETF
Standards Track. In fact, its status section explicitly states that "It
does not define an Internet standard of any kind."

That it was registered at IANA by initiative of the IESG/IETF as being
obsolete due to the presumption of the latter or the RFC's author (or him
not being clear enough on the subject, let alone not having demonstrated
sufficient experience in the field of application of the said media type
to date) has no bearing for (at least) my recommendation regarding that,
as using that so-called obsolete media type is the best current practice
due to the maximum possible support of it among current and possibly future
user agents. Much in contrast to the alternatives defined by that RFC.

The explanation for "obsolete" given to me by the RFC's author, Bjoern
Hoermann, in de.comp.lang.javascript was that according to RFC4288, the only
alternatives would have been "common" and "limited use", while the former
was strongly objected and the latter was seen as not being heavily endorsed
by the participants of the respective discussion.[1] Which IMHO would beg
the question whether any of those people has ever written a cross-browser
client-side script in an ECMAScript implementation.

http://pointedears.de/scripts/test/mime-types/


PointedEars
___________
[1] <[email protected]>
 
K

korisu

PointedEars, do you do anything besides troll this group? Almost every
thread I see has a near-immediate reply from you arguing the most
trivial of semantics, and answering none of the OP's questions.
Perhaps you should get a hobby. Or a job. ;)




Back on topic, I was thinking about this same thing a month ago, while
organizing my common PHP/XSL/CSS scripts through includes/imports, and
while wondering why Javascript didn't have this functionality, I saw a
similar simple include() function in the DHTML Lemmings code. It'd be
nice to replicate PHP's require[_once]() and include[_once]()
functions for Javascript, if only for the sake of maintainable
modularity from within a single script.

Since this capability isn't present in base Javascript, you'd have to
work it into the DOM from within the script, as RobG said. From what
I've thought of so far, there are two situations that an include()
function would have to take into account:

1. the document is still loading.
document.write() should work fine in this case. I don't know why
the HTML string needs to be broken up, but apparently it's critical;
the Lemmings script did that too.
2. the document has been completely loaded.
document.write() would overwrite the existing page, but I'd think
that a document.createElement("script") etc. would work in this case.
Haven't tried it yet.

include_once() would be much more useful, but its situations are
proportionally more complicated:
1. the document has been completely loaded.
Something like this [pseudocode]: if
($A(document.getElementsByTagName("script")).every(function
(scriptElement) { return resolveURI(scriptElement.src) !=
resolveURI(newScript) })) include(newScript);
2. the document is still loading.
A little lost on this one; any suggestions would be awesome. If I'm
thinking correctly, any <script/> elements created prior to the
current point of execution should be available in the DOM (similar to
calling a function to alter a <div> after the <div> tag has been
closed), and so #1 might work here too. Some trial-and-error behavior
analysis would answer a lot of questions. (There's still a big gray
area with <script defer>... I'm not touching that one for now. :p)



What I'm wondering here, though, is how the browser reacts to these
<script> elements when they're dynamically created, and what's
available in the scope surrounding the creation call. If I call
document.write("<script src='otherFile.js'></script>") within an
external JS file (say, externalFile.js), and otherFile.js creates
someFunction(), would I be able to call someFunction() in the
externalFile.js code right after I call document.write()? And how
about in the case that I call document.createElement() after the
document has loaded? I'd think that the order of these things would be
rigidly defined somewhere, since Javascript can control the DOM and is
loaded through <script/>, which itself exists in the DOM. This part
seems crucial to the reliability of such a function.


The practical upshot of such a function (with hard, dependable
behavior, of course) would be that you could wait to include some of
your more monstrous JS files until a function is called that requires
their inclusion. In particular, at my work, there's a set of about a
dozen library JS files that are included en masse in any framework-
based page. I've come across too many situations where I'm in a tiny
utility script and need one of the higher-level functions, and have
had to pick through the script to see which of the lower-level
functions I need to include in order to make it work.



I'd love to hear more from anyone who's looked into implementing this.
 
A

ASM

En réponse à korisu qui écrivit, en date du : 7/09/07 7:35, le message
suivant :
PointedEars, do you do anything besides troll this group? Almost every
thread I see has a near-immediate reply from you arguing the most
trivial of semantics, and answering none of the OP's questions.
Perhaps you should get a hobby. Or a job. ;)

may be
no answer = there is no question or it is a bad question ?
Back on topic, I was thinking about this same thing a month ago, (...)
Since this capability isn't present in base Javascript, you'd have to
work it into the DOM from within the script, as RobG said. From what
I've thought of so far, there are two situations that an include()
function would have to take into account: (snip)
I'd love to hear more from anyone who's looked into implementing this.

Some cases here :
<http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
with browser's reactions on different called JS (loaded JS)

where we see that to load a JS script once the page is loaded this code
bellow works most of the time :

function loadJS(fileName)
{
var s = document.createElement('script');
s.src = fileName; //the name of the JS file.
document.getElementById('scriptDiv').appendChild(s);
}
 
A

ASM

En réponse à Randy Webb qui écrivit, en date du : 7/09/07 15:30, le
message suivant :
ASM has already posted the URL to
a page and the code to include a .js file on the fly. I know the code he
posted is dependable because I wrote it :)

Yes it is a copy-past :)

It could be time you give your address and/or name on this page, no ?

(as it is in my bookmarks and I very often site it - without remembering
from where/who it comes )
 
A

ajile

Back on topic, I was thinking about this same thing a month ago, while
organizing my common PHP/XSL/CSS scripts through includes/imports, and
while wondering why Javascript didn't have this functionality, ...

I wondered the same thing about 4 years ago, then decided to create <a
href="http://ajile.iskitz.com/">Ajile</a>. It provides JavaScript with
namespacing, importing, and dynamic script loading support and works
on all of today's major browsers plus many older ones like IE 4, Opera
7 and NS 6.
What I'm wondering here, though, is how the browser reacts to these
<script> elements when they're dynamically created, and what's
available in the scope surrounding the creationcall. If Icall
document.write("<script src='otherFile.js'></script>") within anexternalJSfile(say, externalFile.js), and otherFile.jscreates
someFunction(), would I be able tocallsomeFunction() in the
externalFile.jscode right after Icalldocument.write()? And how
about in the case that Icalldocument.createElement() after the
document has loaded? I'd think that the order of these things would be
rigidly defined somewhere, since Javascript can control the DOM and is
loaded through <script/>, which itself exists in the DOM. This part
seems crucial to the reliability of such a function.

The practical upshot of such a function (with hard, dependable
behavior, of course) would be that you could wait to include some of
your more monstrousJSfiles until a function is called that requires
their inclusion.
...
I'd love to hear more from anyone who's looked into implementing this.

If you're still interested in a solution to your problem, you should
really take a look at Ajile [http://ajile.iskitz.com/]. I'm interested
to hear what you think. If you reply, please reply to this group as I
rarely check the email account I'm using to post.
 
T

Thomas 'PointedEars' Lahn

Randy said:
Thomas 'PointedEars' Lahn said the following on 9/6/2007 5:05 AM:

OK, give me a URL to a document that defines the acceptable MIME types
for the type attribute of a Script Element *and* to a document that
defines that acceptable standard.

There isn't, and you know it. Which does not make the mentioned decision
a good one.
text/javascript is obsolete.

Theoretically. Practically, it isn't, period. It was a Bad Thing to
standardize it *and* declare it "obsolete" at the same time ("common" would
have been reasonable -- I still wonder what those people were smoking), one
that should be reverted/corrected ASAP.
The only reason it is used is because that is all the W3C Validator will
allow and still spit out a "This is valid (X)HTML" message.

Nonsense. Some UAs will not even execute the script code if there is no
`type' and no `language' attribute for the `script' element, and rightly so.


EOD

PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top