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