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

Discussion in 'Javascript' started by shotokan99, Sep 5, 2007.

  1. shotokan99

    shotokan99 Guest

    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
    shotokan99, Sep 5, 2007
    #1
    1. Advertising

  2. shotokan99

    RobG Guest

    On Sep 5, 1:56 pm, shotokan99 <> wrote:
    > 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.


    --
    Rob
    RobG, Sep 5, 2007
    #2
    1. Advertising

  3. shotokan99 wrote:
    > 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:

    <script type="text/javascript" ...>...</script>

    > </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
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Sep 5, 2007
    #3
  4. Randy Webb wrote:
    > Johannes Baagoe said the following on 9/5/2007 5:20 PM:
    >> Randy Webb :
    >>> You forgot to mention that the type attribute is obsolete though.

    >> I sure learn a lot here! Since when is that the case?

    >
    > 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] <>
    --
    "Use any version of Microsoft Frontpage to create your site. (This won't
    prevent people from viewing your source, but no one will want to steal it.)"
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
    Thomas 'PointedEars' Lahn, Sep 6, 2007
    #4
  5. shotokan99

    korisu Guest

    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.
    korisu, Sep 7, 2007
    #5
  6. shotokan99

    ASM Guest

    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);
    }

    --
    sm
    ASM, Sep 7, 2007
    #6
  7. shotokan99

    ASM Guest

    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 )
    ASM, Sep 7, 2007
    #7
  8. shotokan99

    Guest

    On Sep 7, 1:35 am, korisu <> wrote:
    >
    > 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.
    , Sep 18, 2007
    #8
  9. Randy Webb wrote:
    > Thomas 'PointedEars' Lahn said the following on 9/6/2007 5:05 AM:
    >> Randy Webb wrote:
    >>> Johannes Baagoe said the following on 9/5/2007 5:20 PM:
    >>>> Randy Webb :
    >>>>> You forgot to mention that the type attribute is obsolete though.
    >>>> I sure learn a lot here! Since when is that the case?
    >>> 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."

    >
    > 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
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Sep 19, 2007
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Scott Allen
    Replies:
    8
    Views:
    10,906
    Scott Allen
    May 2, 2004
  2. Rob R. Ainscough
    Replies:
    3
    Views:
    311
    Rob R. Ainscough
    Jun 14, 2005
  3. Jim Adamson

    Defer the call of an external .js file

    Jim Adamson, Dec 15, 2004, in forum: Javascript
    Replies:
    2
    Views:
    119
  4. Mellow Crow
    Replies:
    6
    Views:
    410
    Richard Cornford
    Nov 4, 2005
  5. Neo Geshel
    Replies:
    36
    Views:
    318
    OmegaJunior
    Mar 18, 2007
Loading...

Share This Page