This page is for the Webservant. Use links above
to escape.It is absolutely essential to observe the order in which these scripts are called —that is to say the order in which control passes from one script to another. You cannot call a function unless the script has already been scanned in which that function is written.
So, for example, in cStartup.js you can use a function that is written in that script, or the earlier run script cLibrary.js but not a function in cMajor.js because that script has not yet run.
Also, you cannot call a function that refers to a global variable unless that variable has been defined previously.
For example, the function SideBar() is written in cLibrary.js which is scanned before cStartup.js. Does this mean we can safely call the SideBar() function in cStartup.js? No, because the function uses the variable KEY[05] and that variable is not defined until cMajor.js is scanned after cStartup.js. It's tricky, isn't it?
Obviously the order and logic of the control scripts has been very carefully thought out, and that logic needs to be revisited when attempting to make changes to the scripts.
Keep in mind, when making changes to scripts, that browsers cache scripts, and may use one script from a cache while fetching another script from the server. This mixed bag of old and new scripts can cause pages to render improperly (how improperly is the worry!) until the browser updates all the scripts.
Where possible, make changes that are backward compatible. In other words the control system will still work reasonably well, and the page will still look reasonably good, even if a browser is using a mix of out-of-date and updated scripts. This is easier said than done. Sometimes if changing a function or style definition you can write a new one with a new name and leave the old one unchanged in place for six months.
On any given page of simplybible.com many elements are automatically controlled by Javascript files.
This includes the page environment —banner, header, footer, and the Sidebar. For these elements, only a few very short lines of code are required on each page.
The complex coding for the page environment is managed by scripts. These are called at the head of each web page. The few short lines of code required look like this...
<!--CONTROL--> <script type="text/javascript" src="cLibrary.js"></script> <script>var FName="f60e.htm";</script> <script type="text/javascript" src="cStartup.js"></script> <script>document.write(cMinor);</script> <script type="text/javascript" src="cMajor.js"></script> </head> <body>
The above code is complete except that the file name "f60e.htm" is just an example, and in some cases extra lines are inserted as next explained...
Extra lines referencing other scripts may be added to the Control section on certain pages. For example...
<script type="text/javascript" src="cQuest.js"></script>
...is added when (and only when) a page contains quiz or puzzle elements. On most pages, however, control consists of only five lines referencing four scripts.
These lines can be seen in the source code for any page. (Open a page in a browser, then go to View/Source.)
The value of FName (also stored in FName) is "hardwired" (entered directly) on to the page as shown above. The datum is not discovered automatically from the location.href string, because the latter method precludes using an alias as next explained...
The datum for FName is usually the page's own file name, but not always. We might prefer to place various parts of a study on separate pages. But we want each part to share the same environment (banner, sidebar, footer). So the datum for FName on all parts of the study will be the same. It will be the primary file name, the one that receives an environment via the Minor script —usually the file name of Part 1 of a lesson set. The file name of Part 2 will be given to the Alias variable (and also to Alias). So the line on the page for Part 2 would run something like this:
<script>var FName="f60e.htm"; Alias="f60j.htm";</script>
In the above instance, f60e.htm is the primary part of a lesson set, and f60j.htm is a subsequent part in the same lesson set, borrowing its environment from the first. This means that, in the Minor script, the only place the alias file name needs to occur is where its environment should differ from that of the primary page. In Minor functions reference the Alias stem directly from a=AliasStem because the stem sent to the Minor functions is from FilenameStem which is the stem of FName.
By the way, the alias file name stem is inserted into the FNI (File name index in cStartup.js) in the same datum as the primary, delimited by a pipe character. Example "109|10o|10p" —a primary followed by two aliases.
The aim of using this alias system is two-fold. First it reduces code in the scripts. Second (as suggested above) it changes a purely linear structure for a series of lessons, to a more three-dimensional series structure. That structure looks (typically) like this:
__>__>__>__>__>__>__>__>__>__> 1
__ __ __ __ __ 2
__ __ 3
In a series, there might be ten lessons. Each lesson has a front page (1) which is given an environment including PREV, NEXT, LIST links to the other lessons. However some lessons may have more than one page (represented by 2 and 3 in the diagram above). These multiple pages of a lesson all have the same identity (FName) because they all are parts of the one lesson. The file names of pages subsequent to the first are therefore considered to be aliases.
So the purpose of this alias system, is to break up the content of longer lessons. Of course there is no requirement to split all lengthy lessons in this way. It is just one more option. It does have the advantage that it allows the user to absorb longer lessons in parts rather than suffering information overload.