Where to put page-specific JavaScript

Discussion in 'Javascript' started by Christopher Nelson, Feb 26, 2007.

  1. I have a little menu system which essentially takes HTML like:

    <div id='foo'></div>

    and retrieves foo.shtml from the server and inserts it inside the
    <div>. But sometimes I'd like foo.shtml to look like:

    <script language='JavaScript'>
    ...do something AJAX-y
    </script>
    <div></div>

    so that the script fills in the page. I've hacked together something
    that inserts the foo.shtml into foo's div then does a
    fooDiv.getElementsByTagName('script') and uses eval() on them and it
    works most of the time in some brossers but it seems hackish and
    somewhat dangerous and it doesn't work everywhere. Surely there's an
    AJAX idiom (or even a DOM built-in) to execute scripts as parts of
    pages load. Can someone enlighten me? TIA.
     
    Christopher Nelson, Feb 26, 2007
    #1
    1. Advertising

  2. Christopher Nelson

    Randy Webb Guest

    Christopher Nelson said the following on 2/26/2007 11:38 AM:
    > I have a little menu system which essentially takes HTML like:
    >
    > <div id='foo'></div>
    >
    > and retrieves foo.shtml from the server and inserts it inside the
    > <div>. But sometimes I'd like foo.shtml to look like:
    >
    > <script language='JavaScript'>
    > ...do something AJAX-y
    > </script>
    > <div></div>
    >
    > so that the script fills in the page. I've hacked together something
    > that inserts the foo.shtml into foo's div then does a
    > fooDiv.getElementsByTagName('script') and uses eval() on them and it
    > works most of the time in some brossers but it seems hackish and
    > somewhat dangerous and it doesn't work everywhere. Surely there's an
    > AJAX idiom (or even a DOM built-in) to execute scripts as parts of
    > pages load. Can someone enlighten me? TIA.


    I am vaguely familiar with dynamically loading scripts, so, this thread
    may help you. You will find more information and links about the problem
    you have than you probably wanted to know :)

    <URL:
    http://groups.google.com.au/group/comp.lang.javascript/browse_frm/thread/7e23f42490c301de/3441a1cc21869a10?lnk=gst&q=createTextNode+IE+Randy+Web&rnum=1&hl=en#3441a1cc21869a10>

    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Feb 26, 2007
    #2
    1. Advertising

  3. On Feb 26, 1:01 pm, Randy Webb <> wrote:
    > Christopher Nelson said the following on 2/26/2007 11:38 AM:
    >
    >
    >
    > > I have a little menu system which essentially takes HTML like:

    >
    > > <div id='foo'></div>

    >
    > > and retrieves foo.shtml from the server and inserts it inside the
    > > <div>. But sometimes I'd like foo.shtml to look like:

    >
    > > <script language='JavaScript'>
    > > ...do something AJAX-y
    > > </script>
    > > <div></div>

    >
    > > so that the script fills in the page. I've hacked together something
    > > that inserts the foo.shtml into foo's div then does a
    > > fooDiv.getElementsByTagName('script') and uses eval() on them and it
    > > works most of the time in some brossers but it seems hackish and
    > > somewhat dangerous and it doesn't work everywhere. Surely there's an
    > > AJAX idiom (or even a DOM built-in) to execute scripts as parts of
    > > pages load. Can someone enlighten me? TIA.

    >
    > I am vaguely familiar with dynamically loading scripts, so, this thread
    > may help you. You will find more information and links about the problem
    > you have than you probably wanted to know :)
    >
    > <URL:http://groups.google.com.au/group/comp.lang.javascript/browse_frm/thr...>


    Thanks. I wish that thread ended, "And this is the best way to do
    it..." :-( It seems that the most portable method of getting scripts
    loaded is creating script elements and setting the scr property. At
    http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/ I found:

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

    With most of the corresponding column green. Is that an accurate
    summary? For my situation, it seems that rather than having foo.shtml
    with an embedded script tag, I should have foo.shtml with some
    structure and a companion foo.js which gets loaded into that structure
    with the code above. Or am I missing the boat somehow?
     
    Christopher Nelson, Feb 26, 2007
    #3
  4. On Feb 26, 2:50 pm, "Christopher Nelson" <> wrote:
    > On Feb 26, 1:01 pm, Randy Webb <> wrote:
    >
    >
    >
    > > Christopher Nelson said the following on 2/26/2007 11:38 AM:

    >
    > > > I have a little menu system which essentially takes HTML like:

    >
    > > > <div id='foo'></div>

    >
    > > > and retrieves foo.shtml from the server and inserts it inside the
    > > > <div>. But sometimes I'd like foo.shtml to look like:

    >
    > > > <script language='JavaScript'>
    > > > ...do something AJAX-y
    > > > </script>
    > > > <div></div>

    >
    > > > so that the script fills in the page. I've hacked together something
    > > > that inserts the foo.shtml into foo's div then does a
    > > > fooDiv.getElementsByTagName('script') and uses eval() on them and it
    > > > works most of the time in some brossers but it seems hackish and
    > > > somewhat dangerous and it doesn't work everywhere. Surely there's an
    > > > AJAX idiom (or even a DOM built-in) to execute scripts as parts of
    > > > pages load. Can someone enlighten me? TIA.

    >
    > > I am vaguely familiar with dynamically loading scripts, so, this thread
    > > may help you. You will find more information and links about the problem
    > > you have than you probably wanted to know :)

    >
    > > <URL:http://groups.google.com.au/group/comp.lang.javascript/browse_frm/thr...>

    >
    > Thanks. I wish that thread ended, "And this is the best way to do
    > it..." :-( It seems that the most portable method of getting scripts
    > loaded is creating script elements and setting the scr property. Athttp://members.aol.com/_ht_a/hikksnotathome/loadJSFile/I found:
    >
    > function cElement(fileName) {
    > var s = document.createElement('script');
    > s.src = fileName; //the name of the JS file.
    > document.getElementById('scriptDiv').appendChild(s);
    > }
    >
    > With most of the corresponding column green. Is that an accurate
    > summary? For my situation, it seems that rather than having foo.shtml
    > with an embedded script tag, I should have foo.shtml with some
    > structure and a companion foo.js which gets loaded into that structure
    > with the code above. Or am I missing the boat somehow?


    It seems Michael Foster thinks this is the way to go:

    http://www.cross-browser.com/x/lib/view.php?sym=xLoadScript
     
    Christopher Nelson, Feb 26, 2007
    #4
  5. Christopher Nelson

    Randy Webb Guest

    Christopher Nelson said the following on 2/26/2007 4:31 PM:
    > On Feb 26, 2:50 pm, "Christopher Nelson" <> wrote:
    >> On Feb 26, 1:01 pm, Randy Webb <> wrote:
    >>
    >>
    >>
    >>> Christopher Nelson said the following on 2/26/2007 11:38 AM:
    >>>> I have a little menu system which essentially takes HTML like:
    >>>> <div id='foo'></div>
    >>>> and retrieves foo.shtml from the server and inserts it inside the
    >>>> <div>. But sometimes I'd like foo.shtml to look like:
    >>>> <script language='JavaScript'>
    >>>> ...do something AJAX-y
    >>>> </script>
    >>>> <div></div>
    >>>> so that the script fills in the page. I've hacked together something
    >>>> that inserts the foo.shtml into foo's div then does a
    >>>> fooDiv.getElementsByTagName('script') and uses eval() on them and it
    >>>> works most of the time in some brossers but it seems hackish and
    >>>> somewhat dangerous and it doesn't work everywhere. Surely there's an
    >>>> AJAX idiom (or even a DOM built-in) to execute scripts as parts of
    >>>> pages load. Can someone enlighten me? TIA.
    >>> I am vaguely familiar with dynamically loading scripts, so, this thread
    >>> may help you. You will find more information and links about the problem
    >>> you have than you probably wanted to know :)
    >>> <URL:http://groups.google.com.au/group/comp.lang.javascript/browse_frm/thr...>

    >> Thanks. I wish that thread ended, "And this is the best way to do
    >> it..." :-(


    Maybe I should post a reply to it and say "This is the best way to do
    it" and refer to the function you listed below.

    >> It seems that the most portable method of getting scripts
    >> loaded is creating script elements and setting the scr property.


    Yes, that is the best way of doing it.

    >> At http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/I found:
    >>
    >> function cElement(fileName) {
    >> var s = document.createElement('script');
    >> s.src = fileName; //the name of the JS file.
    >> document.getElementById('scriptDiv').appendChild(s);
    >> }


    Yes, that is a function I wrote about 3 or 4 years ago to load a .js
    file on the fly. And to date, I have not come up with a better course to
    do it.

    >> With most of the corresponding column green. Is that an accurate
    >> summary?


    Yes, a very accurate summary based on multiple people testing the page
    for me to come up with those results.

    >> For my situation, it seems that rather than having foo.shtml
    >> with an embedded script tag, I should have foo.shtml with some
    >> structure and a companion foo.js which gets loaded into that structure
    >> with the code above. Or am I missing the boat somehow?


    That is probably the simplest way. You would load pageName.shtml and
    pageName.js. Another option is to scan the innerHTML for SCRIPT
    elements. If it has a source, load the .js file. If it has content, then
    insert that content into the page.

    > It seems Michael Foster thinks this is the way to go:
    >
    > http://www.cross-browser.com/x/lib/view.php?sym=xLoadScript


    About the only difference between that function and mine (aside from the
    feature tests) is that his is appending to the head element where mine
    appends it in a DIV element that is solely for the purpose of appending
    script elements (hence it's name of scriptDiv). The reason mine is
    written that way is that when you load a file, load another, load
    another, and so on, every single one of those files will remain a memory
    load. Placing the script blocks in a div element makes it easier to
    remove the. You can either cycle through the children of scriptDiv and
    remove all the script blocks or simply set it's innerHTML to "" and the
    previously loaded scripts are dumped and available for Garbage
    Collection and free up the memory.

    Thread that shows how to parse out script elements:

    <URL:
    http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/fb360f782ef616ad/26af58522a10514d?lnk=gst&q=randy+webb+loadjsfile+getElementsByTagName&rnum=1>

    Another on removing script elements:

    <URL:
    http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/56498ef2fabcefc8/2c55e50ba6f6fc66?lnk=gst&q=loadjsfile&rnum=8#2c55e50ba6f6fc66>

    Right now Google Groups doesn't seem to be finding searches correctly
    for the last 6 months or so. If you can find some threads with
    loadJSFile in them a lot of them refer to other threads where some other
    aspects of it were talked about. Another is the first thread where it
    points to other threads (that I cant find via a Google Search).

    This is another where it is discussed about injecting script blocks
    (that are parsed out of the innerHTML block) and some of the associated
    problems:

    <URL:
    http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/b1cee183e87aadc2/cf32cc0137dee3f2?lnk=gst&q=loadjsfile&rnum=1#cf32cc0137dee3f2>

    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Feb 27, 2007
    #5
  6. Christopher Nelson

    -Lost Guest

    "Randy Webb" <> wrote in message
    news:...
    > Christopher Nelson said the following on 2/26/2007 4:31 PM:
    >> On Feb 26, 2:50 pm, "Christopher Nelson" <> wrote:
    >>> On Feb 26, 1:01 pm, Randy Webb <> wrote:
    >>>>
    >>>> Christopher Nelson said the following on 2/26/2007 11:38 AM:
    >>>>> I have a little menu system which essentially takes HTML like:
    >>>>> <div id='foo'></div>
    >>>>> and retrieves foo.shtml from the server and inserts it inside the
    >>>>> <div>. But sometimes I'd like foo.shtml to look like:
    >>>>> <script language='JavaScript'>
    >>>>> ...do something AJAX-y
    >>>>> </script>
    >>>>> <div></div>
    >>>>> so that the script fills in the page. I've hacked together something
    >>>>> that inserts the foo.shtml into foo's div then does a
    >>>>> fooDiv.getElementsByTagName('script') and uses eval() on them and it
    >>>>> works most of the time in some brossers but it seems hackish and
    >>>>> somewhat dangerous and it doesn't work everywhere. Surely there's an
    >>>>> AJAX idiom (or even a DOM built-in) to execute scripts as parts of
    >>>>> pages load. Can someone enlighten me? TIA.
    >>>> I am vaguely familiar with dynamically loading scripts, so, this thread
    >>>> may help you. You will find more information and links about the problem
    >>>> you have than you probably wanted to know :)
    >>>> <URL:http://groups.google.com.au/group/comp.lang.javascript/browse_frm/thr...>
    >>> Thanks. I wish that thread ended, "And this is the best way to do
    >>> it..." :-(

    >
    > Maybe I should post a reply to it and say "This is the best way to do it" and refer to
    > the function you listed below.
    >
    >>> It seems that the most portable method of getting scripts
    >>> loaded is creating script elements and setting the scr property.

    >
    > Yes, that is the best way of doing it.
    >
    >>> At http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/I found:
    >>>
    >>> function cElement(fileName) {
    >>> var s = document.createElement('script');
    >>> s.src = fileName; //the name of the JS file.
    >>> document.getElementById('scriptDiv').appendChild(s);
    >>> }

    >
    > Yes, that is a function I wrote about 3 or 4 years ago to load a .js file on the fly.
    > And to date, I have not come up with a better course to do it.
    >
    >>> With most of the corresponding column green. Is that an accurate
    >>> summary?

    >
    > Yes, a very accurate summary based on multiple people testing the page for me to come up
    > with those results.
    >
    >>> For my situation, it seems that rather than having foo.shtml
    >>> with an embedded script tag, I should have foo.shtml with some
    >>> structure and a companion foo.js which gets loaded into that structure
    >>> with the code above. Or am I missing the boat somehow?

    >
    > That is probably the simplest way. You would load pageName.shtml and pageName.js.
    > Another option is to scan the innerHTML for SCRIPT elements. If it has a source, load
    > the .js file. If it has content, then insert that content into the page.
    >
    >> It seems Michael Foster thinks this is the way to go:
    >>
    >> http://www.cross-browser.com/x/lib/view.php?sym=xLoadScript

    >
    > About the only difference between that function and mine (aside from the feature tests)
    > is that his is appending to the head element where mine appends it in a DIV element that
    > is solely for the purpose of appending script elements (hence it's name of scriptDiv).
    > The reason mine is written that way is that when you load a file, load another, load
    > another, and so on, every single one of those files will remain a memory load. Placing
    > the script blocks in a div element makes it easier to remove the. You can either cycle
    > through the children of scriptDiv and remove all the script blocks or simply set it's
    > innerHTML to "" and the previously loaded scripts are dumped and available for Garbage
    > Collection and free up the memory.


    Hrmm... I assume you forgot the word script in "easier to remove the." So anyway, I was
    wondering if you load however many scripts, you can at some point remove them and they can
    still be available to the script?

    (Admittedly, I did not test it. Forgive my laziness!)

    Or we are just talking about getting rid of scripts that are no longer used?

    -Lost
     
    -Lost, Feb 27, 2007
    #6
  7. On Feb 26, 9:28 pm, Randy Webb <> wrote:
    > ...
    > > It seems Michael Foster thinks this is the way to go:

    >
    > > http://www.cross-browser.com/x/lib/view.php?sym=xLoadScript

    >
    > About the only difference between that function and mine (aside from the
    > feature tests) is that his is appending to the head element where mine
    > appends it in a DIV element that is solely for the purpose of appending
    > script elements (hence it's name of scriptDiv). ...


    He has another function which keeps track of scripts so that they
    aren't loaded twice and it may -- I don't recall -- set things up so
    they can be deleted. I don't really understand what difference it
    makes -- in general, of specific to any browser -- whether the script
    is in the head or body.
     
    Christopher Nelson, Feb 27, 2007
    #7
  8. On Feb 26, 9:28 pm, Randy Webb <> wrote:
    > ...
    > >> For my situation, it seems that rather than having foo.shtml
    > >> with an embedded script tag, I should have foo.shtml with some
    > >> structure and a companion foo.js which gets loaded into that structure
    > >> with the code above. Or am I missing the boat somehow?

    >
    > That is probably the simplest way. You would load pageName.shtml and
    > pageName.js. Another option is to scan the innerHTML for SCRIPT
    > elements. If it has a source, load the .js file. If it has content, then
    > insert that content into the page.
    > ...


    I'm not clear on what innerHTML you're referring to. If I have a
    foo.shtml:

    <script src='foo.js'></script>
    ...some content here...

    and bar.shtml:

    <script type='text/javascript'>
    ...some code here...
    </script>
    ...some content here...

    I imagine a function which:

    1. Gets the .shtml file from the server
    2. Replaces the target div's innerHTML with the text returned
    3. Uses div.getElementsByTagName('script') to find all the scripts
    in the
    new content
    a. If the script had a src attribute, gets the js from the server
    or
    b. If the script had content, extracts its innerHTML
    then
    Insert the script text in scriptDiv or the head or something

    This makes my suggested naming convention more flexible (foo.shtml can
    use something other than or in addition to foo.js). My concern is
    that IE7's been doing weird things as I play and I've read that
    innerHTML isn't always supported.
     
    Christopher Nelson, Feb 27, 2007
    #8
  9. Christopher Nelson

    Randy Webb Guest

    -Lost said the following on 2/27/2007 3:00 AM:
    > "Randy Webb" <> wrote in message
    > news:...
    >> Christopher Nelson said the following on 2/26/2007 4:31 PM:
    >>> On Feb 26, 2:50 pm, "Christopher Nelson" <> wrote:


    <snip>

    >>> It seems Michael Foster thinks this is the way to go:
    >>>
    >>> http://www.cross-browser.com/x/lib/view.php?sym=xLoadScript

    >> About the only difference between that function and mine (aside from the feature tests)
    >> is that his is appending to the head element where mine appends it in a DIV element that
    >> is solely for the purpose of appending script elements (hence it's name of scriptDiv).
    >> The reason mine is written that way is that when you load a file, load another, load
    >> another, and so on, every single one of those files will remain a memory load. Placing
    >> the script blocks in a div element makes it easier to remove the. You can either cycle
    >> through the children of scriptDiv and remove all the script blocks or simply set it's
    >> innerHTML to "" and the previously loaded scripts are dumped and available for Garbage
    >> Collection and free up the memory.

    >
    > Hrmm... I assume you forgot the word script in "easier to remove the."


    Yes, somehow it got removed before posting.

    > So anyway, I was wondering if you load however many scripts, you can at some point remove
    > them and they can still be available to the script?


    They would be available until they get Garbage Collected.

    >
    > (Admittedly, I did not test it. Forgive my laziness!)
    >
    > Or we are just talking about getting rid of scripts that are no longer used?


    Getting rid of scripts no longer being used at the time.
    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Feb 27, 2007
    #9
  10. Christopher Nelson

    Randy Webb Guest

    Christopher Nelson said the following on 2/27/2007 8:10 AM:
    > On Feb 26, 9:28 pm, Randy Webb <> wrote:
    >> ...
    >>> It seems Michael Foster thinks this is the way to go:
    >>> http://www.cross-browser.com/x/lib/view.php?sym=xLoadScript

    >> About the only difference between that function and mine (aside from the
    >> feature tests) is that his is appending to the head element where mine
    >> appends it in a DIV element that is solely for the purpose of appending
    >> script elements (hence it's name of scriptDiv). ...

    >
    > He has another function which keeps track of scripts so that they
    > aren't loaded twice and it may -- I don't recall -- set things up so
    > they can be deleted.


    I can see a possible use for not wanting to load files twice. If he has
    it set up so that it doesn't load files twice then you can't delete them.

    > I don't really understand what difference it makes -- in general,
    > of specific to any browser -- whether the script is in the head or body.


    It makes no difference as long as the order is there that they need to
    be in. Meaning, a script block in the HEAD section can't try to call a
    function in the BODY section until after it is loaded. But that is true
    even if they are all in the body or all in the head section. The major
    reason I use the scriptDiv approach is ease of removing script blocks.
    Then again, all I load is pure data. The only thing in my .js files that
    is not pure data is the very last line. It is a function call to call a
    function in the main page to process the data in that file. It is the
    only foolproof way I have come up with to know for sure the .js file has
    loaded to that point.

    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Feb 28, 2007
    #10
  11. Christopher Nelson

    Randy Webb Guest

    Christopher Nelson said the following on 2/27/2007 8:21 AM:
    > On Feb 26, 9:28 pm, Randy Webb <> wrote:
    >> ...
    >>>> For my situation, it seems that rather than having foo.shtml
    >>>> with an embedded script tag, I should have foo.shtml with some
    >>>> structure and a companion foo.js which gets loaded into that structure
    >>>> with the code above. Or am I missing the boat somehow?

    >> That is probably the simplest way. You would load pageName.shtml and
    >> pageName.js. Another option is to scan the innerHTML for SCRIPT
    >> elements. If it has a source, load the .js file. If it has content, then
    >> insert that content into the page.
    >> ...

    >
    > I'm not clear on what innerHTML you're referring to.


    Me saying the innerHTML was wrong. What you have to do is retrieve all
    the script blocks from the container and process them. That is another
    benefit of the scriptDiv approach.

    allScripts=document.getElementById('container').getElementsByTagName('script');

    Now, you loop through allScripts (it is a collection) and handle each
    script block. If it has a .src attribute you insert a .js file. If it
    has text then you create an element and set its .text property.

    > If I have a foo.shtml:
    >
    > <script src='foo.js'></script>
    > ...some content here...
    >
    > and bar.shtml:
    >
    > <script type='text/javascript'>
    > ...some code here...
    > </script>
    > ...some content here...
    >
    > I imagine a function which:
    >
    > 1. Gets the .shtml file from the server
    > 2. Replaces the target div's innerHTML with the text returned
    > 3. Uses div.getElementsByTagName('script') to find all the scripts
    > in the
    > new content
    > a. If the script had a src attribute, gets the js from the server
    > or
    > b. If the script had content, extracts its innerHTML
    > then
    > Insert the script text in scriptDiv or the head or something


    That is precisely what you have to do. The benefit of the scriptDiv is
    you can simply use removeChild and remove all the script blocks or set
    scriptDiv's innerHTML to "" to remove any old content.

    > This makes my suggested naming convention more flexible (foo.shtml can
    > use something other than or in addition to foo.js). My concern is
    > that IE7's been doing weird things as I play and I've read that
    > innerHTML isn't always supported.


    What kind of weird things with IE7? Other than createTextNode (which is
    broken with script elements in all IE's) I am unaware of any problems
    with IE7 and dynamically creating script elements.

    As for innerHTML, what modern browser doesn't support it? I don't know
    of one personally but there may be one.
    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Feb 28, 2007
    #11
  12. On Feb 28, 12:45 am, Randy Webb <> wrote:
    > Christopher Nelson said the following on 2/27/2007 8:21 AM:
    > ...
    > > I imagine a function which:
    > > 1. Gets the .shtml file from the server
    > > 2. Replaces the target div's innerHTML with the text returned
    > > 3. Uses div.getElementsByTagName('script') to find all the scripts
    > > in the new content
    > > a. If the script had a src attribute, gets the js from the server
    > > or
    > > b. If the script had content, extracts its innerHTML
    > > then
    > > Insert the script text in scriptDiv or the head or something

    >
    > That is precisely what you have to do. The benefit of the scriptDiv is
    > you can simply use removeChild and remove all the script blocks or set
    > scriptDiv's innerHTML to "" to remove any old content.


    OK. I'm still struggling to understand JavaScript scoping and
    persistence rules. If I read a dynamic page's <script> element's
    innerHTML, create a new script node, set that node's innerHTML, and
    add that node as a child to scriptDiv, and then remove that script
    node from scriptDiv, do functions defined in that script continue to
    exist in the browser or do they only exist in the source text while
    it's around?

    As I sketched earlier, I imagine my pages having two types of scripts:
    those that define functions to set up an environment and those that
    are, essentially, onload handlers to invoke that environment. If I
    have:

    <script src='foo.js'></script>
    <script language='JavaScript'>
    aFooFunction();
    </script>

    I'd like to cache foo.js's definitions against the possibility of
    reviewing this page later. I can do that with xSmartLoadScript()
    which puts the functions in the header and only retrieves them the
    first time. But I only want aFooFunction() executed once. If I
    append a new script node to a scriptDiv every time I load the page,
    I'll be creating lots of nodes that get executed once. If I want that
    code to be executed once, I'm tempted to set up:

    <script src='foo.js'></script>
    <script language='JavaScript'>
    aFooFunction();
    </script>
    <div id='fooScriptDiv'></div>

    or something then when I find innerHTML in a script tag, create a new
    script, add the innerHTML, append the new script node to fooScriptDiv
    and immediately delete it. Or, at least, leave it there with the
    knowledge that it'll get flushed when that dynamic content is replaced
    by another file. My concern is that I don't know how soon I can
    delete it. I've found that when I add a src-based script to the
    document then immediately eval() code that invokes a function defined
    in that script that the script fails with an error saying that the
    function isn't defined. How can I know when the scr is processed?

    > > This makes my suggested naming convention more flexible (foo.shtml can
    > > use something other than or in addition to foo.js). My concern is
    > > that IE7's been doing weird things as I play and I've read that
    > > innerHTML isn't always supported.

    >
    > What kind of weird things with IE7?


    I don't have good notes but I know if was behaving strangely when I
    was working with it a couple of days ago.

    > ...
    > As for innerHTML, what modern browser doesn't support it? I don't know
    > of one personally but there may be one.


    I may have been reading old notes or notes on old browsers.
     
    Christopher Nelson, Feb 28, 2007
    #12
  13. On Feb 27, 8:21 am, "Christopher Nelson" <> wrote:
    > On Feb 26, 9:28 pm, Randy Webb <> wrote:
    > I imagine a function which:
    >
    > 1. Gets the .shtml file from the server
    > 2. Replaces the target div's innerHTML with the text returned
    > 3. Uses div.getElementsByTagName('script') to find all the scripts
    > in the new content
    > a. If the script had a src attribute, gets the js from the server
    > or
    > b. If the script had content, extracts its innerHTML
    > then
    > Insert the script text in scriptDiv or the head or something
    >
    > This makes my suggested naming convention more flexible (foo.shtml can
    > use something other than or in addition to foo.js). My concern is
    > that IE7's been doing weird things as I play and I've read that
    > innerHTML isn't always supported.


    In IE7, div.getElementsByTagName('script') is returning an empty array
    even when I can clearly see <script> in the responseText:

    var e = document.getElementById(id);
    e.innerHTML = req.responseText;

    alert('req.responseText:'+req.responseText);

    var scripts = e.getElementsByTagName('script');
    alert(scripts.length+' scripts found for '+id);
    if (scripts.length > 0) {
    for (var i = 0; i < scripts.length; ++i) {
    var s = scripts;
    if (s.innerHTML) {
    var x = document.createElement('script');
    x.innerHTML = s.innerHTML;
    var h = document.getElementsByTagName('head');
    h[0].appendChild(x);
    h[0].removeChild(x);
    }
    if (s.src) {
    xSmartLoadScript(s.src);
    }
    }
    }

    This works in Firefox and Opera. It appears that IE isn't updating
    the DOM tree when I set the div's innerHTML.
     
    Christopher Nelson, Feb 28, 2007
    #13
  14. Christopher Nelson

    Randy Webb Guest

    Christopher Nelson said the following on 2/28/2007 11:23 AM:
    > On Feb 27, 8:21 am, "Christopher Nelson" <> wrote:
    >> On Feb 26, 9:28 pm, Randy Webb <> wrote:
    >> I imagine a function which:
    >>
    >> 1. Gets the .shtml file from the server
    >> 2. Replaces the target div's innerHTML with the text returned
    >> 3. Uses div.getElementsByTagName('script') to find all the scripts
    >> in the new content
    >> a. If the script had a src attribute, gets the js from the server
    >> or
    >> b. If the script had content, extracts its innerHTML
    >> then
    >> Insert the script text in scriptDiv or the head or something
    >>
    >> This makes my suggested naming convention more flexible (foo.shtml can
    >> use something other than or in addition to foo.js). My concern is
    >> that IE7's been doing weird things as I play and I've read that
    >> innerHTML isn't always supported.

    >
    > In IE7, div.getElementsByTagName('script') is returning an empty array
    > even when I can clearly see <script> in the responseText:
    >
    > var e = document.getElementById(id);
    > e.innerHTML = req.responseText;
    >
    > alert('req.responseText:'+req.responseText);


    Does the very first item in the responseText happen to be a script
    element? One thing I do know about IE7 is that if the very first element
    is a script block then it gets fubar'ed. The solution I came up with was
    to add an empty element prior to the string to get around it.

    <URL:
    http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/56498ef2fabcefc8/f79391b2eb1ebe1f?lnk=gst&q=randy+webb+br+script+dynamic&rnum=2#f79391b2eb1ebe1f>

    Is the thread where it was talked about. In testing locally I can't
    duplicate the problem unless I make the first element a script block.

    If that is not the issue can you give a URL to a test page I can look at?

    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 1, 2007
    #14
  15. Christopher Nelson

    Randy Webb Guest

    Christopher Nelson said the following on 2/28/2007 9:36 AM:
    > On Feb 28, 12:45 am, Randy Webb <> wrote:
    >> Christopher Nelson said the following on 2/27/2007 8:21 AM:
    >> ...
    >>> I imagine a function which:
    >>> 1. Gets the .shtml file from the server
    >>> 2. Replaces the target div's innerHTML with the text returned
    >>> 3. Uses div.getElementsByTagName('script') to find all the scripts
    >>> in the new content
    >>> a. If the script had a src attribute, gets the js from the server
    >>> or
    >>> b. If the script had content, extracts its innerHTML
    >>> then
    >>> Insert the script text in scriptDiv or the head or something

    >> That is precisely what you have to do. The benefit of the scriptDiv is
    >> you can simply use removeChild and remove all the script blocks or set
    >> scriptDiv's innerHTML to "" to remove any old content.

    >
    > OK. I'm still struggling to understand JavaScript scoping and
    > persistence rules. If I read a dynamic page's <script> element's
    > innerHTML, create a new script node, set that node's innerHTML, and
    > add that node as a child to scriptDiv, and then remove that script
    > node from scriptDiv, do functions defined in that script continue to
    > exist in the browser or do they only exist in the source text while
    > it's around?


    Once you remove the code it is open to be Garbage Collected. Until it is
    Garbaged it will remain. Otherwise it is gone as soon as you remove it.

    > As I sketched earlier, I imagine my pages having two types of scripts:
    > those that define functions to set up an environment and those that
    > are, essentially, onload handlers to invoke that environment. If I
    > have:
    >
    > <script src='foo.js'></script>
    > <script language='JavaScript'>
    > aFooFunction();
    > </script>
    >
    > I'd like to cache foo.js's definitions against the possibility of
    > reviewing this page later. I can do that with xSmartLoadScript()
    > which puts the functions in the header and only retrieves them the
    > first time. But I only want aFooFunction() executed once. If I
    > append a new script node to a scriptDiv every time I load the page,
    > I'll be creating lots of nodes that get executed once. If I want that
    > code to be executed once, I'm tempted to set up:
    >
    > <script src='foo.js'></script>
    > <script language='JavaScript'>
    > aFooFunction();
    > </script>
    > <div id='fooScriptDiv'></div>
    >
    > or something then when I find innerHTML in a script tag, create a new
    > script, add the innerHTML, append the new script node to fooScriptDiv
    > and immediately delete it. Or, at least, leave it there with the
    > knowledge that it'll get flushed when that dynamic content is replaced
    > by another file.


    Yes, it will get flushed if you removeChild on the div element when you
    want to load more:

    Remove all child elements of scriptDiv
    Add new children to scriptDiv

    > My concern is that I don't know how soon I can delete it.


    I have never worried about it using the above order. If you empty out
    the div before you append more then I have never run into an issue with
    it. Even if the second set of scripts have a duplicate function name.

    > I've found that when I add a src-based script to the
    > document then immediately eval() code that invokes a function defined
    > in that script that the script fails with an error saying that the
    > function isn't defined. How can I know when the scr is processed?


    The only way that I have found to reliable call a function in an
    external file that is dynamically loaded is to put the function call at
    the end of the file.

    foo.js:

    //lots of code here

    someFunctionToExecute()

    //end of foo.js

    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 1, 2007
    #15
  16. On Feb 28, 10:25 pm, Randy Webb <> wrote:
    > Christopher Nelson said the following on 2/28/2007 11:23 AM:
    > > In IE7, div.getElementsByTagName('script') is returning an empty array
    > > even when I can clearly see <script> in the responseText:

    >
    > > var e = document.getElementById(id);
    > > e.innerHTML = req.responseText;

    >
    > > alert('req.responseText:'+req.responseText);

    >
    > Does the very first item in the responseText happen to be a script
    > element? One thing I do know about IE7 is that if the very first element
    > is a script block then it gets fubar'ed. The solution I came up with was
    > to add an empty element prior to the string to get around it.
    >
    > <URL:http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...>
    >
    > Is the thread where it was talked about. In testing locally I can't
    > duplicate the problem unless I make the first element a script block.
    >
    > If that is not the issue can you give a URL to a test page I can look at?


    Yes, that's the issue. What a weird bug. I could have looked for
    that for a decade or so without your clue. Thanks!

    I've got:

    var e = document.getElementById(id);
    e.innerHTML = '<br>'+req.responseText;

    var h = document.getElementsByTagName('head')[0];

    var scripts = e.getElementsByTagName('script');
    alert(scripts.length+' scripts found for '+id);
    for (var i = 0; i < scripts.length; ++i) {
    var s = scripts;
    if (s.innerHTML) {
    var x = document.createElement('script');
    x.innerHTML = s.innerHTML;
    h.appendChild(x);
    h.removeChild(x);
    }
    if (s.src) {
    xSmartLoadScript(s.src);
    }
    }

    And IE7 gives me an "Unknown runtime error" on "x.innerHTML =
    s.innerHTML". Firefox and Opera are happy with that code. :-(
     
    Christopher Nelson, Mar 1, 2007
    #16
  17. On Feb 28, 10:30 pm, Randy Webb <> wrote:
    > Christopher Nelson said the following on 2/28/2007 9:36 AM:
    > ...
    > > I've found that when I add a src-based script to the
    > > document then immediately eval() code that invokes a function defined
    > > in that script that the script fails with an error saying that the
    > > function isn't defined. How can I know when the scr is processed?

    >
    > The only way that I have found to reliable call a function in an
    > external file that is dynamically loaded is to put the function call at
    > the end of the file.
    >
    > foo.js:
    >
    > //lots of code here
    >
    > someFunctionToExecute()
    >
    > //end of foo.js


    My testing so far seems to support the idea that I can: 1) add a
    script element with a src value which contains function definitions,
    2) add a script element with innerHTML (with a prefixed <br>) which
    invokes a function, 3) immediately remove the script element with the
    innerHTML. I guess I'll see if that really works on all the browsers
    I care about when I get IE to complaining about lines that are just
    fine!
     
    Christopher Nelson, Mar 1, 2007
    #17
  18. Christopher Nelson

    Randy Webb Guest

    Christopher Nelson said the following on 3/1/2007 9:30 AM:
    > On Feb 28, 10:25 pm, Randy Webb <> wrote:
    >> Christopher Nelson said the following on 2/28/2007 11:23 AM:
    >>> In IE7, div.getElementsByTagName('script') is returning an empty array
    >>> even when I can clearly see <script> in the responseText:
    >>> var e = document.getElementById(id);
    >>> e.innerHTML = req.responseText;
    >>> alert('req.responseText:'+req.responseText);

    >> Does the very first item in the responseText happen to be a script
    >> element? One thing I do know about IE7 is that if the very first element
    >> is a script block then it gets fubar'ed. The solution I came up with was
    >> to add an empty element prior to the string to get around it.
    >>
    >> <URL:http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...>
    >>
    >> Is the thread where it was talked about. In testing locally I can't
    >> duplicate the problem unless I make the first element a script block.
    >>
    >> If that is not the issue can you give a URL to a test page I can look at?

    >
    > Yes, that's the issue. What a weird bug. I could have looked for
    > that for a decade or so without your clue. Thanks!
    >
    > I've got:
    >
    > var e = document.getElementById(id);
    > e.innerHTML = '<br>'+req.responseText;
    >
    > var h = document.getElementsByTagName('head')[0];
    >
    > var scripts = e.getElementsByTagName('script');
    > alert(scripts.length+' scripts found for '+id);
    > for (var i = 0; i < scripts.length; ++i) {
    > var s = scripts;
    > if (s.innerHTML) {
    > var x = document.createElement('script');
    > x.innerHTML = s.innerHTML;


    x.text = s.innerHTML;

    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 1, 2007
    #18
  19. Christopher Nelson

    Randy Webb Guest

    Christopher Nelson said the following on 3/1/2007 9:39 AM:
    > On Feb 28, 10:30 pm, Randy Webb <> wrote:
    >> Christopher Nelson said the following on 2/28/2007 9:36 AM:
    >> ...
    >>> I've found that when I add a src-based script to the
    >>> document then immediately eval() code that invokes a function defined
    >>> in that script that the script fails with an error saying that the
    >>> function isn't defined. How can I know when the scr is processed?

    >> The only way that I have found to reliable call a function in an
    >> external file that is dynamically loaded is to put the function call at
    >> the end of the file.
    >>
    >> foo.js:
    >>
    >> //lots of code here
    >>
    >> someFunctionToExecute()
    >>
    >> //end of foo.js

    >
    > My testing so far seems to support the idea that I can: 1) add a
    > script element with a src value which contains function definitions,
    > 2) add a script element with innerHTML (with a prefixed <br>) which
    > invokes a function,


    Don't set the script elements innerHTML, set it's .text property. See
    the other reply about it.

    --
    Randy
    Chance Favors The Prepared Mind
    comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 1, 2007
    #19
  20. Christopher Nelson

    VK Guest

    On Feb 27, 11:00 am, "-Lost" <>
    wrote:
    > So anyway, I was
    > wondering if you load however many scripts, you can at some point remove them and they can
    > still be available to the script?


    Yes.
    <script> element is a "delivery shell" for text source being parsed.
    After being successfully parsed you can remove that <script> element -
    or all <script> elements all together from the page, it has no effect
    on the execution context. Think of egg shells in the barn and happy
    chickens on the backyard. What effect does it make on chikens if you
    clean up the barn from the egg shells? Same for <script> elements and
    the execution context.
     
    VK, Mar 1, 2007
    #20
    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. Eric
    Replies:
    0
    Views:
    547
  2. Nunux
    Replies:
    0
    Views:
    410
    Nunux
    Sep 4, 2003
  3. =?Utf-8?B?SmF2?=

    Is ViwState Page-Specific or UserControl-Specific

    =?Utf-8?B?SmF2?=, Aug 16, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    546
    =?Utf-8?B?SmF2?=
    Aug 16, 2006
  4. Gabriel Rossetti
    Replies:
    3
    Views:
    555
    Jerry Hill
    Apr 25, 2008
  5. mazdotnet
    Replies:
    2
    Views:
    405
    Alexey Smirnov
    Oct 2, 2009
Loading...

Share This Page