{"id":16798,"date":"2015-08-26T05:01:19","date_gmt":"2015-08-25T19:01:19","guid":{"rendered":"http:\/\/www.rjmprogramming.com.au\/ITblog\/?p=16798"},"modified":"2015-08-26T14:06:35","modified_gmt":"2015-08-26T04:06:35","slug":"external-javascript-genericity-primer-tutorial","status":"publish","type":"post","link":"https:\/\/www.rjmprogramming.com.au\/ITblog\/external-javascript-genericity-primer-tutorial\/","title":{"rendered":"External Javascript Genericity Primer Tutorial"},"content":{"rendered":"
\"External<\/a>

External Javascript Genericity Primer Tutorial<\/p><\/div>\n

We want to talk about some External Javascript usage tactics today in the context of toggling the HTML sup<\/a> element’s .innerHTML (ie. wording) specifically (we’ll explain why, later). External Javascript (as distinct from “inline” or Internal Javascript) gathers your client side logic from files loaded into the <head> … <\/head> header section of your HTML via an HTML script<\/a> tag element containing a src= parameter pointing to where to find the External Javascript file. But is that all? Please read on.<\/p>\n

External Javascript (which we first really talked about, and contrasted to Internal Javascript, here at this blog with PHP + JavaScript + HTML Primer Tutorial<\/a>) is a good way to go for some pretty obvious and maybe a bit less obvious reasons, respectively …<\/p>\n

    \n
  1. External Javascript increases code modularity … and then perhaps less obviously …<\/li>\n
  2. External Javascript usage can increase genericity, which we hope to illustrate today, by highlighting the interplay and relationship the called External Javascript has with its calling HTML (or PHP or ASP.Net or whatever else you use to code web pages)<\/li>\n<\/ol>\n

    Today’s External Javascript calls into play …<\/p>\n

      \n
    1. the calling address bar URL (ie. document.URL) – examining …\n