Bottom

We have now reached the often promised and long awaited step-by-step. Here we shall proceed methodically through the steps required to integrate your web pages into the AEDOK Suitetm of Websites & Domains. And rather than provide tedious examples for study, we have already setup your index.html so that it is fully integrated. Further, we have included in this one page all the necessary and critical components, as well as many of the optional ones, that one needs to understand for the integration of just about any page. So all we have to do is use it as our fully integrated example, not a group of distinct and often times unrelated examples, which have their purpose, but not here.

Here. we shall simply start at the top of the index.html page and go through all the important lines.

Then, all you must do is add the content.

Finally, we shall take the template.html page and show how to re-spec it for a new fully integrated page. This is because although analyzing something that is working is very educational, it is not the same as taking something that is not, and making it so.

We now proceed. Line numbers are approximate.

Examination of index.html

Edit

index.html

Item

title

Find

tag

< title >

line

Note

between < title > and < /title >

Form

Case-insensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), under( _ ), and vertical( | )

Perfect

Need not be letter perfect

Descript

A page's title is spec between the tag pair title and is free form textual information describing the page.

Discuss

A page's title is of course no mystery but what is crucial, is that it is not of the form to which one is accustomed in a book. It does not say, Index of the Website. Imagine you are doing a web search for starting something, would you click on something that says, Index of the Website if you had the choice of clicking on Find everything you need to get started?

Do a number of searches and you will observe that the larger, more professional companies lure the reader in with authoritative declarations.

Don't say things that are false, but be gung-ho. It is actually more of an advertisement than a title.

Further, you can use the vertical( | ) as a very effective attention getter.

Find everything you need to get started | Complete Stock of Items | Competitive Pricing

Item

creation date

Find

tag

< meta name= "creation date" content="" >

line

Format

Universal Date Format

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), comma( , ), and colon( : )

Perfect

We don't know how picky they are

Descript

A page's creation date is spec in textual Universal Date Format enclosed in quotes( " " ) following content=.

Discuss

A page's creation date might not appear to be that important , and indeed technically it is optional, but remember, we are creating intellectual documents, some hopefully for archival storage. An archiving program is going to want to know when this document was created.

As to the topic of case-sensitivity, we do not know for certain that it is case-sensitive, but one thing for certain is that archives are generally run by bureaucrats. No need to take risks in dealing with a possibly argumentative archiving program.

content="Sunday, July 18th, 2010, 5:15 pm"

Item

all_all__css_default.css

Find

comment

<--- Dimensions(tm), CSS Specification --->

line

Find

tag

< link rel="StyleSheet" href= "../all/all_all__css_default.css" type="text/css" media="screen" >

line

Note

We shall discuss only the href="../all/all_all__css_default.css" part, but always use all the parts shown.

Format

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), slash( / ), under( _ )

Perfect

Must be letter perfect

Descript

A , that is, an address relative to the page in which the reference is found, in this case index.html, and enclosed in quotes( " " ).

Analysis

all_all__css_default.css contains important scripts referenced by this page, and indeed all pages in the AEDOK Suitetm of Websites & Domains. It's spec must be letter perfect in the form of a , that is, an address relative to the page in which the reference is found, in this case index.html.

all_all__css_default.css itself is always found in the AEDOK directory all/ and all/ is at level 3 which is depth 1. Directory all/ is at the same level and depth as the highest subdomain. This means that directory all/ is at the same level and depth as subdomain edu and subdomain ent, in other words, edu.aedok.org and ent.aedok.net.

Discuss

The issue is, how to get to all/ from where this page index.html is located. That is the purpose of the which is commonly referred to as just relative address. And it is quite simple. Simply count the number of levels between where you are and where you're going: and add one(1).

The logical question that arises is, "Why do we have to add one(1)? The answer is because even if we were at the same level as all/ we could not go directly to all/. A specification of all/ from here would be interpreted as a subdirectory of here. Therefore one must back up one(1) directory level in order to then go forward to all/.

Assume you are knowItAll.edu.aedok.org and your root directory is therefore edu/knowItAll.
We would have to back up one(1) level to get to edu/ which is at the same level as all/. Then add one(1) more for a total of two(2). The result is: ../../all/all_all__css_default.css

Item

all_all__js.js

Find

comment

< !-- Dimensions(tm), JS Specification -->

line

Find

tag

< script language="javaScript" src= "../all/all_all__js.js" >< /script >

line

Note

We shall discuss only the href="../all/all_all__js.js" part, but always use all the parts shown.

Format

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), slash( / ), under( _ )

Perfect

Must be letter perfect

Descript

A , that is, an address relative to the page in which the reference is found, in this case index.html, and enclosed in quotes( " " ).

Analysis

all_all__js.js contains critical scripts referenced by this page, and indeed all pages in the AEDOK Suitetm of Websites & Domains. It's spec must be letter perfect in the form of a , that is, an address relative to the page in which the reference is found, in this case index.html.

all_all__js.js itself is always found in the AEDOK directory all/ and all/ is at level 3 which is depth 1. Directory all/ is at the same level and depth as the highest subdomain. This means that directory all/ is at the same level and depth as subdomain edu and subdomain ent, in other words, edu.aedok.org and ent.aedok.net.

Discuss

Item

debug

Find

comment

// Dimensions(tm), Scripts

line

Find

variable

var debug=0;

line

Note

We exited script and are now reentering. Theoretically, we could have simply stayed in script. But we prefer to have the all_all__js.js definition above as a unit unto itself.

Format

javascript numeric variable.

Form

numeric( 0-9 ). []Values.

Perfect

Must be letter perfect

Descript

A local string variable used to indicate debug mode or not. Value of zero( 0 ) is off. Value of one( 1 ) is on.
There are other []values.
Terminated by a semicolon( ; ).

Analysis

If it is desired to see a trace of what Dimensionstm thinks you want it to do as it is loading this specific page, turn this variable on( 1 ), otherwise leave it off( 0 ).
[]The tracing functionality is described in detail.

Discuss

This should be done only for a brief period because when on, it is on for any reference to that specific page. Clearly, if this were a functioning page, one would not want users to be confused and annoyed by the very tedious and persistent alerts that are issued.

Though we shall not go into programming techniques, we should say that it is possible to place additional references to the same variables at numerous places. Only the first occurrence needs the var portion.

var debug=0;
.
.
.
debug=1;
.
.
.
debug=0;

Item

iam

Find

varable

var iam="index.html";

line

Format

javascript string variable and this page's technical page name containing a []frameset-relative address all terminated by a semicolon( ; ).

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), under( _ )

Perfect

Must be letter perfect

Descript

A local string variable used to contain the name of this page and which may be used by any scripts on this page.

The page name itself must have a []frameset-relative address.

All terminated by a semicolon( ; ).

Analysis

It is not necessary to use a variable such as iam to specify the page name. One may simply enter the page name into the parameter field of the individual script as needed. However as some pagenames become quite lengthy, if and when a page name is required more than once, this is fertile ground for typos. So we enter the page name into a variable and can then refer simply to the variable which is a much shorter spec.

Also, soon we may be defining spr which very often has the appearance similar to iam. Therefore it is convenient to have the two(2), one above the other, for visual comparison.

The page name must have a []frameset-relative address not a because the page will not be loading itself. Note that this name is the name of the page itself not the name of another page. This name is primarily for the purpose of the frameset which needs to know where to find the page in the event of a single page request.

This page's name and address, in this case iam, will be used by the single initLoad150801() ^script and any initFrame150801() scripts in reference to said frameset, all to be discussed shortly.

Be sure to specify the semicolon( ; ) after the statement .

Confuse

The following will be discussed in greater detail in the initLoad150801() step shortly, but we point it out here so that it does not appear that what is spec here is contradicting what is spec there.

The []frameset-relative address is with respect to the frameset that is loading the specific page, not necessarily the frameset that is being spec in the initLoad150801() itself.

What does this mean? framesets can be, and in fact generally are, nested. The first frameset you spec in initLoad150801() (or initFrame150801()) is going to be in an AEDOK directory and it loads the AEDOK logo and other things. Into the main work frame, f_main_work it will then load another frameset. And that frameset could even load another frameset. Eventually a frameset is loaded that wants to load your page, which is the page we are talking about here in the variable iam. That frameset is the one that needs to know where to find the page we are talking about. So the frameset-relative address is with respect to that frameset that is actually doing the load of the page under consideration.

The initLoad150801() step, a few steps below here, explains how to spec the right frameset-relative address. And the examples below show that it is really quite simple once one understands the relationships.

Eg1

Asm: knowItAll.edu.aedok.org so root is edu/knowItAll.
Asm: page to load is index.html.
Asm: frameset that's loading index.html is in root.
Asm: index.html is in root.
Therefore you would spec:
var iam="index.html";
Because to get from the frameset to the page we do not need to either back up or go forward. We're already there.

Eg2

Asm: knowItAll.edu.aedok.org so root is edu/knowItAll.
Asm: page to load is anotherPage.html.
Asm: frameset that's loading anotherPage.html is in root.
Asm: anotherPage.html is in dir1/.
Therefore you would spec:
var iam="dir1/anotherPage.html";
Because to get from the frameset to the page we do not need to back up, but we do need to go forward.

Eg3

Asm: knowItAll.edu.aedok.org so root is edu/knowItAll.
Asm: page to load is index.html.
Asm: frameset that's loading index.html is in dir2/.
Asm: index.html is in root.
Therefore you would spec:
var iam="../index.html";
Because to get from the frameset to the page we need to back up and stop there.

Eg4

Asm: knowItAll.edu.aedok.org so root is edu/knowItAll.
Asm: page to load is anotherPage.html.
Asm: frameset that's loading anotherPage.html is in dir2/.
Asm: anotherPage.html is in dir1/.
Therefore you would spec:
var iam="../dir1/anotherPage.html";
Because to get from the frameset to the page we need to back up out of dir2/ and then go forward to dir1/. In the words used earlier, even though we are already at the level of dir1/, because dir1/ and dir2/ are at the same level, we would then add one(1) more for a total of one(1). We have to back around the boundary between the directories.

Item

iamCaller

Find

variable

var iamCaller=iam;

Note

We have just discussed iam and we usually place iamCaller on the same line immediately following iam=.

Format

javascript string variable free format, terminated by a semicolon( ; ). But at this level, AEDOK sets iamCaller equal to iam.

Form

Case-insensitive alphanumeric( a-z , A-Z , 0-9 ), under( _ )

Perfect

Must be letter perfect

Descript

A local string variable used to contain the name of the page or script that called a script, and which may be used by any scripts on this page.

Analysis

As thoroughly discussed, []iamCalleris a concatenation of iam and whatever script called this page. But because this is the beginning, there is no caller to this page. We are not referring here to a single page request we are referring to one script calling another, for tracing purposes. So, from this perspective we are at the beginning and technically the caller is null.

The reason we even bother to define iamCaller is frankly laziness. As a trace, we always specify iamCaller. But as just pointing out there is no caller. However through force of habit there is a tendency to specify iamCaller rather than iam. But if iamCaller is not defined but still used, JavaScript strangles. So we simply defined iamCaller equal to iam.

Item

spr

Find

variable

var spr="";

Note

We have just discussed iam and iamCaller and we usually place spr on the line immediately following iam=

Format

javascript string variable and an alternate page's technical page name containing a []frameset-relative address all terminated by a semicolon( ; ).

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), under( _ )

Perfect

Must be letter perfect

Descript

A local string variable used to contain the name of an alternate page and which may be used by any scripts on this page.

The page name itself must have a []frameset-relative address

All terminated by a semicolon( ; ).

Analysis

It is not necessary to use a variable such as iam or spr or to specify the page name. One may simply enter the page name into the parameter field of the individual script as needed. However as some pagenames become quite lengthy, if and when a page name is required more than once, this is fertile ground for typos. So we enter the page name into a variable and can then refer simply to the variable which is a much shorter spec.

spr refers to single page request. Now read carefully. In the event of a single page request for this page, whose name we have placed in the variable iam, then this page can be loaded. That is simple and straightforward. However, remember that sometimes one does not want to load the page itself which has been referenced but rather a descriptive page to describe the page that has been referenced, or possibly some form of menu or list page that itself references the page that has been reference. or even possibly some introduction to one's website and domain, of a larger scope that might actually have nothing to do directly with the page referenced. There are any number of permutations and combinations. The purpose of var spr is to hold the name of this alternate page in the event you do not wish to load iam in the case of a single page request.

Now, in this particular set up whereby we have set up your index.html page, we do want to load this index.html page in the event of a single page request. So in this case we set spr to null. So the spr line should say:
var spr="";
and also notice the semicolon( ; ) which indicates the end of that statement.

Further, if we had wanted an alternate page name in spr then it is convenient to have the spr assignment directly after the iam assignment so that one can easily compare the two page names, thus:
var iam="../../index.html";
var spr="../../indexAlt.html"";

Item

init()

Find

comment

// Dimensions(tm), Scripts, init() line

Note

init() script is used when it is inappropriate or inconvenient to use initLoad150801() ^script, but has less functionality.

Because in this step-by-step sequence, we are using initLoad150801() ^script, we shall defer until after todoitQ2() script for a review of this script in our copious free time. tm.

Discuss

There are three(3) lines here, each one commented out with JavaScript doubleSlash( // ). The letter( r ) is our indicator that the line is for reference and has no other significance. If the doubleSlash( // ) were removed, so also should be the letter( r ). But don't do it because the first two(2) won't work. They are just for reference. Towit:

Line 1:init() script shown with it's formal parameters in their respective positions. We do this as a convenient reference so one does not have to []look them up. You would never use the script in this manner. Though you could, if you defined all the variables. But in this case it is simpler to just spec them. You don't have to duplicate it in pages you create, though it is in our template and may be deleted therefrom if it appears as clutter to you.

Line 2:init() script shown with descriptions or options in their respective positions. We do this as a convenient reference so one does not have to []look them up. You would never use the script in this manner. It would not work. You don't have to duplicate it in pages you create, though it is in our template and may be deleted therefrom if it appears as clutter to you.

Line 3:init() script shown with parameter values comprable to the initLoad150801() ^script which we are using. You could actually use this reference by removing the comment tag( //r ) and putting a comment tag( //r ) before the un-commented initFrame150801() and initLoad150801() which are next, but this configuration would have less functionality so don't.

Examination of index.html: initFrame150801() script

Item

initFrame150801()

Find

comment

// Dimensions(tm), Scripts, initFrame

line

Defer

initFrame150801() script is optionally used in conjunction with and in addition to initLoad150801() ^script which is next. For this reason, it should be discussed after initLoad150801() ^script. It appears physically and logically first because in fact it must be executed first of the two.

We shall defer until after initLoad150801() ^script and then return here in a subsequent step.

Examination of index.html: initLoad150801() ^script

Item

initLoad150801()

Find

comment

// Dimensions(tm), Scripts, initLoad

line

105

Note

There are three(3) lines here, the first two(2) commented out with JavaScript doubleSlash( // ). The letter( r ) is our indicator that the line is for reference and has no other significance. If the doubleSlash( // ) were removed, so also should be the letter( r ). But don't do it because the first two(2) won't work. They are just for reference. The third one is already live. Towit:

Line 1

//r initLoad150801( initTopSub, initFrameset, initFrame, initIam, initSpr, initType, initPageGroup, initPageTitle, initPageFunc, initPageLevel, initPageIcon, initPageIconAlt, debug, iamCaller )

Line 1: init() script shown with it's formal parameters in their respective positions. We do this as a convenient reference so one does not have to You would never use the script in this manner. Though you could, if you defined all the variables. But in this case it is simpler to just spec them. You don't have to duplicate it in pages you create, though it is in our template and may be deleted therefrom if it appears as clutter to you.

Line 2

//r initLoad150801( "top_SUB", "f_FRAMESET-clf", "f_FRAME", iam, SPR, -1 | 0 | 1, "suite | map | about | help | user | member | content | ..", "About AEDOK", "http | href | domain||controls | func || menu | submenu||intro | detail | form || content | promo || K(tm) | K(tm)_notice | | ads1 | ads2 | adsExternal | ..", 0, "? | ! | ~ | * | ~~", "initPageIconAlt", debug, iamCaller );

Line 2: init() script shown with descriptions or options in their respective positions. We do this as a convenient reference so one does not have to You would never use the script in this manner. It would not work. You don't have to duplicate it in pages you create, though it is in our template and may be deleted therefrom if it appears as clutter to you.

Line 3

initLoad150801( "org_AEDOK" , "org_AEDOK__f_single-page-request_main-clf_ala_com.html" , "f_SE_content" , iam , spr , 0 , "content" , "Welcome" , "intro" , "1" , "!" , "Important Information About Our Services" , debug , iamCaller ); // Actual

Line 3: init() script shown with live parameter values which we are using. This is what we shall be examining here.

A link has been activated from somewhere requesting this index.html page. Here we will be discussing the individual parameter values of the initLoad150801() ^script in order to load this page.

Format

Parameter specific

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), slash( / ), under( _ )

Perfect

Some must be letter perfect, others not

Modus
Operandi

What we shall be covering here are the implications of these functioning specs for this page index.html.

We have provide mouseover links in these discussions directly to the specs and reference material and analyses that we've already covered. Follow these links with your cursor as you read. The information should to your left.

This is a form of interactive presentation that we hope you try to emulate where appropriate, for it is extremely convenient and educational for the reader.

Because this document is not aware of your specific sub-domain, we shall refer to org_edu_yourSub for any additional examples, say for comparative purposes. However, we have checked to ensure that the level and depth of our narration here it is identical to the level and depth of your subdomain, which for verification are level 4 which is depth 2. So aside from changing org_edu_yourSub to the name of your subdomain, there should be no differences. We proceed from left to right.

Parm
1 - 6

Single-Page-Request Loading Specifications

Single-Page-Request Loading Specifications are for the most part required to integrate your web pages into the AEDOK Suitetm of Websites & Domains. But there are variations depending upon circumstances. For this reason, Dimensionstm performs some fairly extensive conflict checking, issuing alerts explaining the conflict. Because some of these conflict checks impose as a slight burden, once fully implemented there will be Level 4 Active Member options to bypass some of the checks.

However, once a page has passed the checks, there is no maintenance required and there is nothing the user can do to cause a problem.

Further, these considerations are only regarding the Single-Page-Request. If for some reason one cannot configure the proper specs, the todoitQtm and the spawntm controls are still functional in dynamic situations (normal website operation), providing of course they are properly spec, and their specs are quite simple and straightforward.

This is not to say that any failure to properly spec can be ignored. For indeed, entering your website through a search or bookmark, is a vital capability. This simply gives one ample time to figure out what is wrong.

Parm 1

initTopSub

org_AEDOK

initTopSub ^{parm 1} is a multi purpose parm that usually specifies the location where the frameset, the next parm initFrameset ^{parm 2}, is located. But when it does, it is only because that location is not already specified in the file name of that initFrameset ^{parm 2} itself using AEDOK notation. So in that regard, it is not actually a necessary parm.

And so if you do specify the location in the filename itself of initFrameset ^{parm 2}, as we have done for this page index.html, using the , then initTopSub is actually seldom required.

However when using custom framesets as describe in initTopSub is required.

Here, initTopSub ^{parm 1} is spec as org_AEDOK.

It is not needed here, but we have specified it so that you can see how it is related to topSubPart which is part 1 of the next parm initFrameset ^{parm 2}.

Parm 2

initFrameset

org_AEDOK__f_single-page-request_main-clf_ala_com.html

initFrameset ^{parm 2} is the frameset containing the frame, the next parm initFrame ^{parm 3}, into which you want to load this page index.html (initIam ^{parm 4}), or the

frameset containing the frameset containing the frame, into which you want to load this page.

framesets can load framesets into their frames.

But what's important to remember is that one specifies the frameset that starts the loading process and the frame to which the page is to be loaded, which essentially ends the loading process, and everything else in between is automatic.

So it does not matter if the frame into which you are loading the page is in the initial frameset which you specify, as long as the frameset you specify will load a frameset which has the frame or itself loads another frameset which has the frame etc.

Here, initFrameset ^{parm 2} is spec as org_AEDOK__f_single-page-request_main-clf_ala_com.html.

The frame we want for this page index.html is in fact not in initFrameset org_AEDOK__f_single-page-request_main-clf_ala_com.html

Parm 3

initFrame

f_SE_content

initFrame ^{parm 3} is the frame into which you want to load this page index.html (initIam ^{parm 4}).

Here, initFrame ^{parm 3} is spec as f_SE_content.

f_SE_content is not in initFrameset:
org_AEDOK__f_single-page-request_main-clf_ala_com.html.

But that frameset loads frameset:
org_AEDOK__f_single-page-request_SE-clf_ala_com.html

into its frame f_main_work, and this second frameset contains f_SE_content. So,

org_AEDOK__f_single-page-request_SE-clf_ala_com.html loads initIam ^{parm 4}, this page index.html, into initFrame ^{parm 3}, here f_SE_content.

Notice the similarity in frameset names.

Parm 4

initIam

index.html

initIam ^{parm 4} is the name (with frameset-relative address) of the page, this page index.html, that you want to load into initFrame ^{parm 3} when a single page request occurs..

Here (in an earlier step when we were discussing the variables debug, iam, iamCaller, and spr) we placed the name and address of the page, this page index.html, in the so for parm 4 we spec iam.

Note that whereas we used to place the page name into the variable iam, we do not use quotes( " " ) here when we because the name of the page is not iam, it is contained in iam.

Parm 5

initSpr

null( "" )

initSpr ^{parm 5} is the name and address of the page, that is not this page index.html, but is an alternate page, that you want to load into initFrame ^{parm 3}. when a single page request occurs.

Here (in an earlier step when we were discussing the variables debug, iam, iamCaller, and spr) we set the variable spr to null, so for parm 5 we spec spr.

Note that whereas we used []quotes( " " ) to place the null into the variable spr, we do not use quotes( " " ) here when we spec spr, because the null is not spr, it is contained in spr.

Had we wanted an alternate page loaded, some descriptive page, alternate index or menu, we would place that name into spr []above where here we used null. Note that because we use the two(2) variables iam and spr on separate lines one above the other, it is easy to compare them for correctness since very often the alternate is a variation upon the the first, such as eg.,
iam=index.html
spr=indexAlt.html, or
spr=index2.html, or
spr=index-2.html, or
spr=index_2.html

Parm 6

initType

initType ^{parm 6} is the []type of page we are loading from an initialization perspective, not a web content perspective. It is in the form of an integer.

Here we have spec 0 which means a regular page, as compared to a frameset, which would have been type 1. Even though we are using framesets to do the load, the type of the page we are loading, this page index.html, is just a common page.

Note that for simplicity we simply spec the 0 as a constant in the parameter field rather than use a variable. It is not our center of attention and it is not likely to change. And because it is an integer, not a string, we do not use quotes( " " ).

Had we wanted, we could have used variables such as with debug, iam, iamCaller, and spr, but frankly that would be a lot of extra work for something which in this manor is so simple.

We use variables generally when something is likely to change. For example debug. Rather than have to say to oneself, "Ok, now which parameter was that debug, is that it?", it is easier to look for the word debug which we also know is at the left margin, and then simply change it. Also, when we do so, it is on for other script calls also.

But in the case of an initType there is little reason.

Parm
7-12

Content Specifications

Content Specifications are optional, as regards to the loading functionality, but again this is not to say that they should be ignored. Content Specifications are concerning common theme and backgrounds. The ambience. And it is desirable to have all pages integrate visually into the AEDOK Suitetm of Websites & Domains, as well as functionally.

But the specs are simple and straightforward. For this reason, Dimensionstm performs very little conflict checking, since most of the specs are subjective.

The worst that results from improper spec is improper theme.

Parm 7

initPageGroup

content

initPageGroup ^{parm 7} is a broad grouping (not fully developed) of the page based on not so much on function as family, for Ktm website mapping ^{not implemented}.

Here we have spec content.

Parm 8

initPageTitle

Welcome

initPageTitle ^{parm 8} is the page title for theme and Ktm website mapping ^{not mplemented}

Here we have spec Welcome because we have assumed it is an introduction to your website and subdomain. With the passage of time it may evolve into a menu.

Parm 9

initPageFunc

intro

initPageFunc ^{parm 9} is a classification of the page based on overall, not specific, function.

Here we have spec intro because we have assumed it is an introduction to your website and subdomain. With the passage of time it may evolve into a menu.

Parm 10

initPageLevel

initPageLevel ^{parm 10} is a very broad classification of the complexity of the page, currently with a range from 1 through 4. When a dynamic reference is generated at your website, (ie, when you link to the page) Ktm uses initPageLevel as a polite notification to the user as to the level of the possible diversion.

Here we have spec 1 because we have assumed it is a simple introduction to your website and subdomain.

Parm 11

initPageIcon

initPageIcon ^{parm 11} is a visual flag. When a dynamic reference is generated at your website, (ie, when you link to the page) Ktm uses initPageIcon as a polite notification to the user about the nature of the link.

Here we have spec imp( ! ) because your introduction to your website and subdomain is a vital piece of information, possibly describing your purpose.

Parm 12

initPageIconAlt

Important Information About Our Services

initPageIconAlt ^{parm 11} is brief textual information which corresponds to initPageIcon. When a dynamic reference is generated at your website, (ie, when you link to the page) Ktm uses initPageIconAlt as a polite notification to the user about the nature of the link.

Here we have spec Important Information About Our Services because your introduction to your website and subdomain is a vital piece of information, possibly describing your purpose.

Parm
13-14

Debug Specifications

Debug Specifications are optional, and are used by you in the event the page won't load and you can't figure out why.

Needed only under extreme circumstances, when the relative addresses just don't seem to work. But most of the time Dimensionstm extensive conflict checking and alerts suffice.

Parm 13

debug

debug

debug ^{parm 13} is essentially an on/off flag to be used to generate a trace in the event the page just won't load.

Here (in an earlier step when we were discussing the variables debug, iam, iamCaller, and spr) we set debug, to 0. so for parm 13 we spec debug.

Parm 14

iamCaller

iamCaller

iamCaller ^{parm 14} is used with debug ^{parm 13} to generate a trace in the event the page just won't load.

Here (in an earlier step when we were discussing the variables debug, iam, iamCaller, and spr) we set iamCaller, to iam. so for parm 13 we spec iamCaller.

Examination of index.html: initFrame150801() script

Item

initFrame150801()

Find

comment

// Dimensions(tm), Scripts, initFrame

line

Now
Return
After
Defer

Having completed the initLoad150801() ^script review above, it is now time to return to the initFrame150801() ^script which we untill now.

initFrame150801() ^script is optionally used in conjunction with and in addition to the initLoad150801() ^script, for the specification of support pages to the page referenced in the initLoad150801() ^script.

In this setup we have done for you, we have elected to use initFrame150801() ^script to demonstrate the flexibility and power afforded you with just a bit of foresight and planning.

Note

Notice that initFrame150801() ^script appears physically and logically before initLoad150801() ^script. The specifications are processed and not used until required.

The
three(3)
contexts
that can
exist at
any time
for any
web page
and how
we have
set them
up for
this
demo

There are seven(7) active lines here, each shall be discussed in turn after this brief intro and game-plan.

First, our over all plan as discussed in the content of your index.html page itself.

From that discussion you should note that we are speaking of 3 different contexts. And in each one we speak of 3 pages: this index.html page, the alligator menu, and the crocodile menu.

In the first context, the single-page-request scenario, the user has clicked on some external link say from a search engine or bookmark, which links directly to this index.html page. In this case, the initLoad150801() ^script detects that it is a single-page-request, performs the necessary steps to establish the frameset and appearance of the website, and only then automatically loads this index.html page into the largest frameset, the content frame. It selected the content frame only because we told it to in the specifications above. We could have specified any other frame we desired.

In the second context, dynamic common scenario, at your website, the user has clicked on the default user control panel > menu which loads this index.html page. In this case, the initLoad150801() ^script detects that the website has already been established, and there is very little for it to do, so then loads this index.html page into the smaller frame, the primary frame. It selected the primary frame only because AEDOK told it to in the link in the default user control panel > menu. AEDOK could have specified any other frame we desired. And you may specified any other frame you desired in your user control panel > menu.

In the third context, dynamic specific scenario, at your website, the user has clicked on one(1) of the two(2) links in this index.html page which loads itself, this index.html page. Yes, this is unusual, because normally from these two links one would have loaded either the alligator menu or the crocodile menu. But we've set this up as a demo just to demonstrate the power and flexibility available to you. In this case, the initLoad150801() ^script detects that the website has already been established, and there is very little for it to do, so then loads this index.html page into the smaller frame, the primary frame. It selected the primary frame only because AEDOK told it to in the links in this index.html page. AEDOK could have specified any other frame we desired. And you may specified any other frame you desired when you appropriately modified this page for your own usage.

So index.html has already been taken care of by the first click in either of the three(3) scenarios. And what we need here are the two(2) (, alligator and crocodile menu) pages times three(3) scenarios which is six(6) initFrame150801() lines to discuss all three(3) scenarios we have established.

So the seven(7) lines are grouped in three(3) pairs, each pair seperated by a single blank comment line, thus:

// Dimensions(tm), Scripts, initFrame
1:var sprNull="";
2:initFrame150801( "org_AEDOK" , ...
3:initFrame150801( "org_AEDOK" , ...
//
4:initFrame150801( "org_AEDOK" , ...
5:initFrame150801( "org_AEDOK" , ...
//
6:initFrame150801( "org_AEDOK" , ...
7:initFrame150801( "org_AEDOK" , ...

Discuss

The parameters on the initFrame150801() are identical to the initLoad150801() even though some may not be required. We do this because it is more convenient to have the same list of parms and skip over the unneeded ones, than to delete them have have the order of the parms become confused.

And their specification is almost trivial if the page has already been properly set up.

The reason for the simplicity is that initFrame150801() concerns itself with the dynamic scenarios, not with the single-page-request scenario. It deals with the support pages you want loaded in addition to any individual page, when that individual page is loaded by you when the user clicks a link at your website. And the support pages should already be defined.

Thus there are no new, tedious, addressing issues. In fact, it's a simple matter of copy / paste, as follows:

go to the support page(s)
find it's initLoad150801()
copy the entire line
paste it where you need the initFrame150801()
change Load to Frame

In this case, we needed to go to only two(2) different pages and copied each initLoad150801()spec three(3) times.

Finally we need only make a few additional changes as will be discussed shortly. But first the plan.

Plan

We shall establish six(6) independent initFrame150801() specs, two(2) each for:

the single-page-request scenario
the dynamic common scenario
the dynamic specific scenario

And addionally a feature we have not yet mentioned, in each of the above two(2) dynamic scenarios, the page loaded (that would be in this demo either the alligator menu or the crocodile menu) can have its own initFrame150801() spec(s) which we shall discuss later.

Notice that although we said above that initFrame150801() does not concern itself with the single-page-request scenario it can be used in the single-page-request scenario, whereby the initLoad150801() concerns itself with the scenario, and handles that entire process.

We shall now discuss in depth the seven(7) lines grouped in three(3) pairs, beginning with an explanation of the var sprNull=""; line, and then on to the single-page-request scenario pair.

And remember, when we say changes that these lines are copies of initLoad150801() specs in their respective pages and already have established values. What we are discussing here are the simple changes to these establish values to make those lines useful for the powerful AEDOK Dimensions tm v 1.0 Web Publishing Platform's group page frame loading process.

Scenario 1 of 3: Single-Page-Request (Support Pages) Scenario

Line 1

var sprNull="";

The spr parm which we shall be discussing shortly, and the associated variable spr that we discussed , are not needed. Some times when a parm is not needed it is best to simply spec a null value. That would be 0 for a numeric value and null( "" ) for a string value. But here, we have quite a long list of parms and we have found that the variables themselves help to delineate portion of the parm list. But, we have decided, as we shall soon be dicussing, to not use iam and since spr is not needed, that would leave us with no visual markers. So purely for visual convenience we have established the variable sprNull which has the required null( "" ) value and which we can now use as a place marker in the parm list.

Line 2-3
Scenario
1 of 3

working
on in this section

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , "f_SE_primary" , "org_edu_knowItAll__menu_alligator.html" , sprNull , 0 , "groupSpr" , "Aligator Menu" , "menu" , "4" , "" , "Aligator Menu" , debug , iamCaller);

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , f_SE_secondary" , "org_edu_knowItAll__menu_crocodile.html" , sprNull , 0 , "groupSpr" , "Crocodile Menu" , "menu" , "4" , "" , "Crocodile Menu" , debug , iamCaller);

Parm
1 - 6

Loading Specifications (for the)
First of three pairs of initFrame150801() specs (dealing with)
Single-Page-Request (Support Pages) Scenario

Changes to Loading Specifications are for the most part of form rather than substance, to aid in the visual clarity. The one notable exception to this of course being initFrame ^{parm 3} the first of two primary aspects of this discussion, the second aspect being initPageGroup ^{parm 7} of the Content Specifications, below.

Parm 1

initTopSub

org_AEDOK

No change to initTopSub ^{parm 1}.

Parm 2

initFrameset

org_AEDOK__f_single-page-request_main-clf_ala_com.html

No change to initFrameset ^{parm 2}.

Parm 3

initFrame

initFrame ^{parm 3} is the first of two primary aspects of this discussion.

Review: For this Single-Page-Request (Support Pages) Scenario, we want:

index.html in the content frame.
org_edu_knowItAll__menu_alligator.html in the primary frame.
org_edu_knowItAll__menu_crocodile.html in the secondary frame.

But index.html has alread been loaded into the content frame, by initLoad150801(), since the init process loads the initLoad150801() page before the initFrame150801() pages,

So set initFrame to f_SE_primary in the first of these two(2) initFrame150801() lines.
So set initFrame to f_SE_secondary in the second of these two(2) initFrame150801() lines.

Parm 4

initIam

org_edu_knowItAll__menu_alligator.html
org_edu_knowItAll__menu_crocodile.html

There is no change to initIam ^{parm 4} value, but for these two(2) pages of six(6) references we decided to not use the variable initIam for the parm, but have chosen instead to put the actual page name in the parm field.

The reason is because it seems easier to look at the six lines and see the page names change as one moves one's eyes up and down, than it is to look at the lines with initIam1, initIam2, etc., and then move one's eyes over to the left column to see the six different lines with the page names, to correlate them, and then move one's eyes back to the six frame specifications and group specifications. It's subjective of course, but we think you will agree after looking at Line 2-3 above.

One can easily compare the alligator to the crocodile and by using sprNull, rather than null( "" ) one realizes that the references to alligator and to the crocodile are indeed the initIam ^{parm 4}.

So for parm 4 we spec the actual page names with their frameset-relative addresses.

AEDOK recommends this technique, you decide.

Note that therefore we do use quotes( " " ).

Parm 5

initSpr

null( "" )

initSpr ^{parm 5} is null( "" ). Remember, even though this is a single-page-request scenario, initSpr ^{parm 5} applies only to the alternate page in the initLoad150801(). What we are dealing with here are additional pages and these cases we always specify the page name in initIam ^{parm 4} as we have done above, and spec initSpr ^{parm 5} null( "" ).

And note further as we discussed in , above, we are using a different variable sprNull simply for visual clarity rather than spec null( "" ) directly.

Parm 6

initType

No change to initType ^{parm 6} which is a regular page, as compared to a frameset, which would have been type 1.

Parm
7-12

Content Specifications (for the)
First of three pairs of initFrame150801() specs (dealing with)
Single-Page-Request (Support Pages) Scenario

Changes to Content Specifications are virtually non-existent. The one notable exception to this of course being initPageGroup ^{parm 7} the second of two primary aspects of this discussion, the first aspect being initFrame ^{parm 3} of the Loading Specifications, above.

Parm 7

initPageGroup

groupSpr

initPageGroup ^{parm 7} is the second of two primary aspects of this discussion.

Our goal is to group load pages. The specification of the group is done here. For the Single-Page-Request (Support Pages) Scenario group which is the first of three groups we want to set up, there is a predefined name. This predefined group name is groupSpr.

So all we have to do is spec: groupSpr for each of these two(2) pages and they will be loaded together in this Single-Page-Request (Support Pages) Scenario.

But additionally, any initFrame150801() spec with a initPageGroup ^{parm 7} whose first 5 letters are not lowercase group is included in the groupSpr group.

In this way, one can do the cut and paste we talked about earlier having to change only the initFrame ^{parm 3} specification, the frame name, to get the proper visual layout configuration.

So, to reiterate, for the Single-Page-Request (Support Pages) Scenario, you can leave the initPageGroup ^{parm 7} unchanged as long as the first 5 letters are not lowercase group, or you can change initPageGroup ^{parm 7} to groupSpr.

Even though we added this feature for convenience,, we still prefer to set initPageGroup ^{parm 7} to groupSpr. Just for clarity.

AEDOK recommends this technique, you decide..

Parm 8

initPageTitle

Alligator Menu
Crocodile Menu

No change to initPageTitle ^{parm 8}.

Parm 9

initPageFunc

menu

No change to initPageFunc ^{parm 9}.
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Parm 10

initPageLevel

No change to initPageLevel ^{parm 10}.
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Parm 11

initPageIcon

null( "" )

No change to initPageIcon ^{parm 11}.
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Note

A quick note that has nothing to do with this index.html analysis that we are doing here.

In this documentation and presentation we may have used the specific Ktm initPageIcon inf( ? ) more than would be appropriate under normal website usage, but have done so here in order to draw your attention to how well it does draw one's attention.

But it is not intended to be a casual attachment to all hyperlinks, but rather, as a polite notification to the user about the generally important nature of the link, beyond what the link itself concerns.

A , is available.

Parm 12

initPageIconAlt

Alligator Menu
Crocodile Menu

No change to initPageIconAlt ^{parm 12}.
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Note

In reference to the note above: However, PLEASE MAKE COPIOUS USE OF THE Ktm initPageIconAlt For, it's intent is to provide usefull information where other websites can not due to limitations in html itself.

Parm
13-14

Debug Specifications

Debug Specifications are always optional and at your discretion.

Parm 13

debug

debug

No change to debug ^{parm 13}.

Parm 14

iamCaller

iamCaller

No change to iamCaller ^{parm 14}.

Summary

We are establishing six(6) independent initFrame150801() specs, two(2) each for:

the single-page-request scenario
the dynamic common scenario
the dynamic specific scenario<

We have just completed the first group, the single-page-request scenario, Line 2-3. The next step is the second group, the dynamic common scenario, Line 4-5.

Scenario 2 of 3: dynamic common (Support Pages) scenario

Note

In this second group, lines 4 & 5, when we say changes we are referring to changes from lines 1 & 2. This is because we want to compare the two scenarios: groupSpr which we have just completed and groupDc which we are now beginning. Otherwise, we would be replowing and old field.

Line 2-3
Scenario
1 of 3

DONE

Repeated here for ana

Line 4-5
Scenario
2 of 3

working
on in this section

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , f_SE_secondary" , "org_edu_knowItAll__menu_alligator.html" , sprNull , 0 , "groupDc" , "Aligator Menu" , "menu" , "4" , "" , "Aligator Menu" , debug , iamCaller);

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , f_SE_content" , "../../../all/all_all__adm_display_blank.html" , sprNull , 0 , "groupDc" , "Blank Page" , "" , 0 , "" , "" , debug , iamCaller);

Parm
1 - 6

Loading Specifications (for the)
Second of three pairs of initFrame150801() specs (dealing with)
Dynamic Common (Support Pages) Scenario

Parm 1

initTopSub

org_AEDOK

No change to initTopSub ^{parm 1}.

Parm 2

initFrameset

org_AEDOK__f_single-page-request_main-clf_ala_com.html

No change to initFrameset ^{parm 2}.

Parm 3

initFrame

Review: Whereas in the single-page-request (Support Pages) scenario we loaded alligator menu into the primary frame and crocodile menu into the secondary frame,

for this dynamic common (Support Pages) Scenario, we want:

index.html in the primary frame.
org_edu_knowItAll__menu_alligator.html in the secondary frame.
org_edu_knowItAll__menu_crocodile.html we will leave out of the picture but want a blank page in the content frame.

But index.html has already been loaded into the primary frame, by the default user control panel > menu, since even on a direct link, the init process loads the initLoad150801() page before the initFrame150801() pages,

So set initFrame to f_SE_secondary in the first of these two(2) initFrame150801() lines.
So set initFrame to f_SE_content in the second of these two(2) initFrame150801() lines.

Parm 4

initIam

org_edu_knowItAll__menu_alligator.html
../../../all/all_all__adm_display_blank

There is no change to initIam ^{parm 4} value, for the alligator line. All we are changing is the location which we did, just above.

But there is a change to the crocodile line because we decided to not display the crocodile menu but instead display a blank page in the content frame.

So for the second line parm 4 we spec the AEDOK blank page (administrative display blank), located in the AEDOK alldirectory at depth 1. So to get to it from org_edu_knowItAll you must back up two(2) levels []plus 1, and then go forward to all, thus:

../../../all/all_all__adm_display_blank

Note

This all/all_all__adm_display_blank is available to all AEDOK Level 4 Active Member as a convenient means of clearing a frame.

It possesses the proper headers and footers and will be displayed in the page theme according to your initPageFunc ^{parm 9} spec.

It even contains the frame name for both user and your convenience. It's a sort of, "This page intentionally left blank."

Parm 5

initSpr

null( "" )

No change to initSpr ^{parm 5}.

Parm 6

initType

No change to initType ^{parm 6}.

Parm
7-12

Content Specifications (for the)
Second of three pairs of initFrame150801() specs (dealing with)
dynamic common (Support Pages) Scenario

Parm 7

initPageGroup

groupDc

Our goal is to group load pages. The specification of the group is done here. For the Dynamic Common (Support Pages) Scenario group which is the second of three groups we want to set up, there is a predefined name. This predefined group name is groupDc.

So all we have to do is spec: groupDc for each of these two(2) pages and they will be loaded together in this Dynamic Common (Support Pages) Scenario.

Parm 8

initPageTitle

Alligator Menu
Blank Page

No change to initPageTitle ^{parm 8} for the first of these two(2) initFrame150801() lines.

But the second changed to a blank page so we have spec Blank Page.

Note

initPageTitle ^{parm 8} is actually any block of html formatted text. So for this blank page you can actually provide brief instructions or a note to your user instead of just Blank Page as we have done here.

Parm 9

initPageFunc

menu
null( "" )

No change to initPageFunc ^{parm 9} for the first of these two(2) initFrame150801() lines.

But the second changed to a blank page so we have spec null( "" ).
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Parm 10

initPageLevel

4
0

No change to initPageLevel ^{parm 10} for the first of these two(2) initFrame150801() lines.

But the second changed to a blank page so we have spec 0.
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Parm 11

initPageIcon

null( "" )

No change to initPageIcon ^{parm 11} for the first of these two(2) initFrame150801() lines.

But the second changed to a blank page so we have spec null( "" ).
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Parm 12

initPageIconAlt

Alligator Menu
null( "" )

No change to initPageIconAlt ^{parm 12} for the first of these two(2) initFrame150801() lines.

But the second changed to a blank page so we have spec null( "" ).
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Parm
13-14

Debug Specifications

Debug Specifications are always optional and at your discretion.

Parm 13

debug

debug

No change to debug ^{parm 13}.

Parm 14

iamCaller

iamCaller

No change to iamCaller ^{parm 14}.

Summary

We are establishing six(6) independent initFrame150801() specs, two(2) each for:

the single-page-request scenario
the dynamic common scenario
the dynamic specific scenario<

We have just completed the second group, the dynamic common scenario, Line 4-5. The next step is the third group, the dynamic specific scenario, Line 6-7.

Scenario 3 of 3: dynamic specific (Support Pages) scenario

Note

In this third group, lines 6 & 7, when we say changes we are referring to changes from lines 1 & 2. This is because we want to compare the three scenarios: groupSpr which we completed earlier, groupDc which we have just completed and groupDs (groupDsA & groupDsC) which we are now beginning.

Line 2-3
Scenario
1 of 3

DONE

Repeated here for ana

Line 4-5
Scenario
2 of 3

DONE

Repeated here for ana

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , f_SE_secondary" , "org_edu_knowItAll__menu_alligator.html" , sprNull , 0 , "groupDc" , "Aligator Menu" , "menu" , 4 , "" , "Aligator Menu" , debug , iamCaller);

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , f_SE_content" , "../../../all/all_all__adm_display_blank.html" , sprNull , 0 , "groupDc" , "Blank Page" , "" , 0 , "" , "" , debug , iamCaller);

Line 6-7
Scenario
3 of 3

working
on in this section

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , f_SE_secondary" , "org_edu_knowItAll__menu_alligator.html" , sprNull , 0 , "groupDsA" , "Aligator Menu" , "menu" , "4" , "" , "Aligator Menu" , debug , iamCaller);

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , f_SE_secondary" , "org_edu_knowItAll__menu_crocodile.html" , sprNull , 0 , "groupDsC" , "Crocodile Menu" , "menu" , "4" , "" , "Crocodile Menu" , debug , iamCaller);

Parm
1 - 6

Loading Specifications (for the)
Third of three pairs of initFrame150801() specs (dealing with)
Dynamic Specific (Support Pages) Scenario

Parm 1

initTopSub

org_AEDOK

No change to initTopSub ^{parm 1}.

Parm 2

initFrameset

org_AEDOK__f_single-page-request_main-clf_ala_com.html

No change to initFrameset ^{parm 2}.

Parm 3

initFrame

Review: Whereas in the single-page-request (Support Pages) scenario we loaded alligator menu into the primary frame and crocodile menu into the secondary frame,

and Whereas in the dynamic common (Support Pages) Scenario we loaded alligator menu into the secondary frame bypassed the crocodile menu and loaded a blank into the content frame,

for this dynamic specific (Support Pages) Scenario, we want:

index.html in the primary frame,
org_edu_knowItAll__menu_alligator.html in the secondary frame
or
org_edu_knowItAll__menu_crocodile.html in the secondary frame depending upon which one the user selects from this index.html page.

But index.html has already been loaded into the primary frame, by the user's selection of either the alligator menu or the crocodile menu, because in this demo we've reloaded index.html page itself from those links, ([]yes, it's unusual) , and on a direct link, the init process loads the initLoad150801() page before the initFrame150801() pages,

So set initFrame to f_SE_secondary in the first of these two(2) initFrame150801() lines.
So set initFrame to f_SE_secondary in the second of these two(2) initFrame150801() lines.

Parm 4

initIam

org_edu_knowItAll__menu_alligator.html
org_edu_knowItAll__menu_crocodile.html

There is no change to initIam ^{parm 4}.

Parm 5

initSpr

null( "" )

No change to initSpr ^{parm 5}.

Parm 6

initType

No change to initType ^{parm 6}.

Parm
7-12

Content Specifications (for the)
Third of three pairs of initFrame150801() specs (dealing with)
dynamic specific (Support Pages) Scenario

Parm 7

initPageGroup

groupDsA
groupDsC

Our goal is to group load pages. The specification of the group is done here. For the Dynamic Specific (Support Pages) Scenario group which is the third of three groups we want to set up, there is a predefined name. This predefined group name is groupDs.

But notice we have not spec groupDs, but rather, groupDsA and groupDsC.

In fact, initPageGroup ^{parm 7} may be any []single word, but for this group selection process used by initFrame150801() it is any []single word as long as the first five letters are exactly lowercase: group.

And notice that this group does not have to have more than one item in it. It is merely a selection filter.

So set initPageGroup to groupDsA in the first of these two(2) initFrame150801() lines.
So set initPageGroup to groupDsC in the second of these two(2) initFrame150801() lines.

So, as a result of the alligator click which is a todoitQ1() ^script call with todoitQpageGroupOverride ^{parm 9} spec as groupDsA, the alligator menu will be loaded into f_SE_secondary specified by the corresponding initFrame (shown above).

And, as a result of the crocodile click (which we have not yet shown) which is a todoitQ1() ^script call with todoitQpageGroupOverride ^{parm 9} spec as groupDsC, the crocodile menu will be loaded into the same f_SE_secondary specified by the corresponding initFrame (shown above).

Thus fulfilling the individual requirements for the dynamic specific (support pages) scenario.

Notice that this is accomplished even though both specs we are discussing here are within the same index.html page.

Analyse

Now at face value this might not appear that remarkable or even useful as indeed in a standard hyperlink reference one has the ability to specify the target frame.

But the power comes from two facts.

First, that one can specify multiple pages in this group, whereas with the standard hyperlink reference one cannot. That alone is extremely convenient. With the standard frame set of the AEDOK Dimensions tm v 1.0 Web Publishing Platform one could easily populate three(3) to four(4) support frames ... with a single click.

But second, in the todoitQ1() ^script call one specifies the initPageGroup, not the frame

So for example if you have dozens of references to the alligator menu, scattered about your intertwined website, and decide to rework the alligator menu so that it is narrower, and decide that it would be better to place it in the primary frame and load another support frame in the secondary frame, this can be done by changing just one single specification.

To change the destination frame of a page having any number of references to it, all one need change is the initFrame (shown above) from (in this example) f_SE_secondary to f_SE_primary.

This initFrame150801() spec containing the initFrame (shown above) would have to be contained within the alligator menu itself (org_edu_knowItAll__menu_alligator.html), not index.html as we have used here in our demonstration. But the logic is similar.

Then, to get that additional support page loaded all one need do is add a single initFrame150801() line. Bingo.

Parm 8

initPageTitle

Alligator Menu
Crocodile Menu

No change to initPageTitle ^{parm 8}.

Parm 9

initPageFunc

menu

No change to initPageFunc ^{parm 9}.
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Parm 10

initPageLevel

No change to initPageLevel ^{parm 10}.
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Parm 11

initPageIcon

null( "" )

No change to initPageIcon ^{parm 11}.
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

No change to initPageIcon ^{parm 11}.

Parm 12

initPageIconAlt

Alligator Menu
Crocodile Menu

No change to initPageIconAlt ^{parm 12}.
However note that this parm is ignored by initFrame150801() ^script so any spec you make is simply for your reference.

Parm
13-14

Debug Specifications

Debug Specifications are always optional and at your discretion.

Parm 13

debug

debug

No change to debug ^{parm 13}.

Parm 14

iamCaller

iamCaller

No change to iamCaller ^{parm 14}.

Summary

We are establishing six(6) independent initFrame150801() specs, two(2) each for:

the single-page-request scenario
the dynamic common scenario
the dynamic specific scenario<

We have just completed the third group, the dynamic specific scenario, Line 6-7. So we have analyzed all three scenarios.
They are repeated below in their completeness, for your analysis.

Line 2-3
Scenario
1 of 3

DONE

Repeated here for ana

Line 4-5
Scenario
2 of 3

DONE

Repeated here for ana

Line 6-7
Scenario
3 of 3

DONE

Repeated here for ana

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , f_SE_secondary" , "org_edu_knowItAll__menu_alligator.html" , sprNull , 0 , "groupDsA" , "Aligator Menu" , "menu" , "4" , "" , "Aligator Menu" , debug , iamCaller);

initFrame150801( "org_AEDOK" , "__f_single-page-request_main-clf_ala_com.html" , f_SE_secondary" , "org_edu_knowItAll__menu_crocodile.html" , sprNull , 0 , "groupDsC" , "Crocodile Menu" , "menu" , "4" , "" , "Crocodile Menu" , debug , iamCaller);

This step-by-step is complete.

Examination of index.html: pakit() script

Item

pakit()

Find

comment

// Dimensions(tm), Scripts, pakit()

line

110

Note

Due to time constraints, this section of the manual has been delayed until all critical components have been completed.

PAKITtm provides useful functionality, of which we shall document ASAP. But it is not a critical component to your installation. You shall be notified, ironically by PAKITtm when this section is complete.

Please include the pakit() ^script lines as you see them here, in each page. Only one(1) is currently active. Details to come.

Now proceed to the next step-by-step.

Examination of index.html: kClose() script

Item

kClose()

Find

comment

// Dimensions(tm), Scripts, kClose()

line

119

Note

Line 1

//r kClose(min,url);

Line 1: kClose() script shown with it's formal parameters in their respective positions. We do this as a convenient reference so one does not have to You would never use the script in this manner. Though you could, if you defined both variables. But in this case it is simpler to just spec them. You don't have to duplicate it in pages you create, though it is in our template and may be deleted therefrom if it appears as clutter to you.

Line 2

//r kClose(1 | 2 | 3 ...);

Line 2: kClose() script shown with descriptions or options in their respective positions. We do this as a convenient reference so one does not have to You would never use the script in this manner. It would not work. You don't have to duplicate it in pages you create, though it is in our template and may be deleted therefrom if it appears as clutter to you.

Line 3

// kClose(1);

Line 3: kClose() script shown with live parameter values which we are using. This is what we shall be examining here.

Format

Integer

Form

Numeric( 0-9 )

Perfect

Must be letter perfect

Descript

The kClose() script reloads Ktm's window, f_main_adm ^frame, after a sufficiently long delay to allow the user to read the page you have loaded therein.

This allows AEDOK to utilize that window for unabashed self-promotion.

It does this by reloading the page in which it is placed.

Discuss

Ktm's window, f_main_adm ^frame, is at the top of the display containing AEDOK's erupting volcano. This frame is designed for presentation of small pages, of the nature of footnotes, references, small diverges, anecdotes, etc., without having that information pop up in one's face, and not requiring the user to close the window.

But, more important than the size of the page is its intention, or perhaps more properly put your intention. If it is a diversion from the main topic at hand, then it is appropriate to put it into Ktm's window and allow the user to determine the ultimate location by using the todoitQtm and the spawntm controls.

After some sufficiently long period of time which of course varies according to the page therein displayed, AEDOK's reuses said window for it's erupting volcano self promotions.

Should you decide to use this window which is f_main_adm ^frame, please activate this closing process by simply removing the doubleSlash( // ) in the page that is being loaded into the frame , thus:

kClose(1);

and setting the value of min ^{parm 1} to the number of minutes to wait before reloading the frame.

Don't set the value to low so that it irritates the user by closing while he's reading, but also don't use an unreasonably large period of time. One(1) to two(2) minutes is usually sufficient unless you've loaded a complex page.

These self promotions allow us to gain customers and eventually revenue which means profit for you too.

When full
function

AEDOK sometimes loads fairly extensive pages into Ktm's window, f_main_adm ^frame, at the top of the display containing AEDOK's erupting volcano. It has a scroll bar so one can examine the page even if it is larger than we've indicated here. One can also use the page up, page down, home and end keys. Also, it extends to the full right side width of the display, so on a medium to large monitor large paragraphs are efficiently stretched out.

When the todoitQtm and the spawntm controls are fully implemented, the user himself will be able to select where such pages are to be displayed anyway. So don't be afraid to display a medium sized, or even larger, page if you have nowhere else to put it and if it is a diversion anyway.

Examination of index.html: todoitQ2() script

Item

todoitQ2()

Find

comment

// Dimensions(tm), Scripts, todoitQ2()

line

124

Note

There are three(3) lines here ...

Line 1

Line 2

Line 3

todoitQ2( "" , "" , "" , "" , "" , 0 , "" , "" , debug , iamCaller );

Format

Parameter specific

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), under( _ )

Perfect

Some must be letter perfect, others not

Descript

Q2 is essential for integrating each page into the AEDOK Suitetm of Websites & Domains. But all of its parameters are optional.

Review

Parameters are first established by one of the init() ^group, usually initLoad150801() ^script. That sets up the static context, ie., the single-page-request context.

But those parameters are then available to todoitQ2() ^script. It can use them or override them. That sets of the dynamic common context, along with initFrame150801() ^script.

Now this point is critical to your understanding. For mechanical reasons, initFrame150801() ^script occurs before initLoad150801() ^script. But, at this point in the step-by-steps, as we are examining todoitQ2() ^script, the initFrame150801() ^script has not actually done it's work, it will not do so until after the dynamic specific context has been established. Now the single-page-request context has been established. And here we establish the dynamic common context by utilizing the override parms.

Next, todoitQ1() ^script which occurs at the precise location of the hyperlink reference (which we shall examine a few step-by-steps down when that reference occurs) can also utilize or override these parameters. That sets up the dynamic specific context, it is specific because it is specifically at the location of the hyperlink reference to the page.

Both initLoad150801() ^script and todoitQ2() ^script are within the specific page itself, so they can't see too far into the future.

But you, the author, know at the point you reference the page what frames you've already used and what frames you intend to use and how you intend to arrange and present your material. That, again, is the dynamic specific context. And planning ahead, you've spec some of that specific arrangement (just as you have done with the common) in one(1) or more initFrame150801() ^scripts.

But whereas you get to actually see the results of the single-page-request context immediately after the page is loaded from an external reference, You will not see the results of your dynamic common context that you are optionally specifying here (in conjunction with initFrame150801() ^script) until after a specific dynamic specific context hyperlink reference to the page occurs. At that point these two(2) dynamic contexts are merged together by way of the specific overriding the common.

Discuss

Most of these variables once established actually never need to be changed. In other words, you don't need to spec anything in the todoitQ2() ^scriptparms that we are examining here, and you won't need to spec anything in the todoitQ1() ^scriptparms we'll examine shortly. But, when you do its usually concerning the frame which is spec in one of the the frame name parms, or a grouping which is spec in the pageGroup parms. At this step-by-step we are examining the todoitQ2() ^script, therefore the establishment of the dynamic common context.

So by utilizing the parms here ( todoitQ2() ^script), you can change the context, otherwise it remains the single-page-request context.

And by utilizing the parms shortly ( todoitQ1() ^script), you can again change the context, otherwise it remains the dynamic common context which you are establishing here.

Summary

In this setup we have done for you, we have not utilized here any of the additional functionality of todoitQ2() ^script) of which we have just spoke. All our dynamic common context work has already been spec in initFrame150801(). So rather than belabor the point, we will now proceed to the next step. Complete functionality of the todoitQ2() ^script) parms that we could have used can be found in the .

Examination of index.html: kDisplay() script Head

Item

kDisplay()

Find

comment

< !-- Dimensions(tm), Scripts, kDisplay() Head -- >

line

132

Note

There are three(3) lines here ...

Line 1

Line 2

Line 3
No
Spaces

< script > kDisplay ( "head/foot&pakitDisplayInlineTreeNodeHrefGet()" , "" , "" , "" , "" , 0 , "" , "" , debug , iamCaller ); < /script >

Line 3
Split
Out

< script >
kDisplay (
"head/foot&pakitDisplayInlineTreeNodeHrefGet()"
, "" , "" , "" , "" , 0 , "" , "" , debug , iamCaller
);
< /script >

Format

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), under( _ )

Perfect

Must be letter perfect

Descript

Due to time constraints, this section of the manual has been delayed until all critical components have been completed.

But here are some quick notes:

kDisplay() ^script head occurrence, the first of two occurrences of kDisplay() ^script, is required to integrate your web pages into the AEDOK Suitetm of Websites & Domains. It generates the proper headers for the various pages and maintains uniformity of style, as we have discussed.

kDisplay() ^script should be placed precisely at the location shown immediately after the end head, towit:
< /head >
< script > kDisplay ( "head/foot ... debug , iamCaller ); < /script >

and it generates a proper begin body:
< body >

Do not add an additional begin body: < body >.

The kDisplay() ^script line which we have shown as Line 3 No Spaces should have no spaces( ). We stretched and split it for easier reading.

Technically, all parameters are optional. If parm 1 is omitted it defaults to what is shown, towit:
head/foot&pakitDisplayInlineTreeNodeHrefGet()

But we prefer to spec to eliminate uncertainty.

With the other parameters which are shown as null( "" ) or zero( 0 ), we prefer to spec as shown so that the positions are already laid out, should we need to activate various parms.

debug and iamCaller have been defined in previous steps and those definitions remain in effect for here.

Analysis

Discuss

Examination of index.html: todoitQ1() script

Item

todoitQ1()

Find

comment

< !-- Dimensions(tm), Scripts, todoitQ1() Demo -- >

line

Note

There are two(2) lines here ...

Colors

Universal

Parm column: Dimensions tm, Thereafter: This Example.

Specific

Lines
1 - 2

< script > todoitQ1 ( "" , "" , "index.html" , "f_SE_primary" , 1 , 1 , "Alligator" , "" , "groupDsA" , "" , "" , 0 , "" , "" , debug , iam ); < /script >

< script > todoitQ1 ( "" , "" , "index.html" , "f_SE_primary" , 1 , 1 , "Crocodile" , "" , "groupDsC" , "" , "" , 0 , "" , "" , debug , iam ); < /script >

Format

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), under( _ )

Perfect

Must be letter perfect

Descript

Analysis

Discuss

Colors

Universal

Parm column: Dimensions tm, Thereafter: This Example.

Specific

Parm 1

func

null( "" )

Not used here, so: Line 1: Spec null( "" ), Line 2: Spec null( "" ).

Parm 2

preTags

null( "" )

Not used here, so: Line 1: Spec null( "" ), Line 2: Spec null( "" ).

Parm 3

url

index.html
index.html

Our goal is to load the index.html into the primary frame in both cases and let it, via the dynamic specific group, load the appropriate alligator/crocodile menu into the secondary frame, so:

Line 1: Spec url as index.html
Line 2: Spec url as index.html

Parm 4

todoitQpageFrameOverride

f_SE_primary
f_SE_primary

Our goal is to load the index.html into the primary frame in both cases and let it, via the dynamic specific group, load the appropriate alligator/crocodile menu into the secondary frame, so:

Line 1: Spec todoitQpageFrameOverride as f_SE_primary
Line 2: Spec todoitQpageFrameOverride as f_SE_primary

Parm 5

click

AEDOK often uses both click and mouseover to activate hyperlinks. Sometimes only one is appropriate. Here we use both. This is the click spec, so:

Line 1: Spec click as 1
Line 2: Spec click as 1

Parm 6

mouse

AEDOK often uses both click and mouseover to activate hyperlinks. Sometimes only one is appropriate. Here we use both. This is the mouse spec, so:

Line 1: Spec mouse as 1
Line 2: Spec mouse as 1

Parm 7

textOrImage1

Alligator
Crocodile

The text we want to hyperlinks in this case is either Alligator or Crocodile, so:

Line 1: Spec textOrImage1 as Alligator
Line 2: Spec textOrImage1 as Crocodile

Parm 8

textOrImage2

null( "" )

Not used here, so: Line 1: Spec null( "" ), Line 2: Spec null( "" ).

Parm 9

todoitQpageGroupOverride

groupDsA
groupDsC

Our goal is to group load pages. The specification of the group is done here. For the Dynamic Specific (Support Pages) Scenario group which is the third of three groups we want to set up, there is a predefined name. This predefined group name is groupDs.

But notice we have not spec groupDs, but rather, groupDsA and groupDsC.

In fact, initPageGroup ^{parm 7} may be any single word, but for this group selection process used by initFrame150801() it is any []single word as long as the first five letters are exactly lowercase: group.

And notice that this group does not have to have more than one item in it. It is merely a selection filter. So:

Line 1: Spec initPageGroup as groupDsA
Line 2: Spec initPageGroup as groupDsC

So, as a result of the alligator click (which we and which is here) which is this todoitQ1() ^script call with todoitQpageGroupOverride ^{parm 9} spec as groupDsA, the alligator menu will be loaded into f_SE_secondary specified by the corresponding initFrame (shown above).

And, as a result of the crocodile click (which is now here) which is this todoitQ1() ^script call with todoitQpageGroupOverride ^{parm 9} spec as groupDsC, the crocodile menu will be loaded into the same f_SE_secondary specified by the corresponding initFrame (shown above).

Thus fulfilling the individual requirements for the dynamic specific (support pages) scenario.

Notice that this is accomplished even though both specs we are discussing here are within the same index.html page.

Parm 10

todoitQpageTitleOverride

null( "" )

Not used here, so: Line 1: Spec null( "" ), Line 2: Spec null( "" ).

Parm 11

todoitQpageFuncOverride

null( "" )

Not used here, so: Line 1: Spec null( "" ), Line 2: Spec null( "" ).

Parm 12

todoitQpageLevelOverride

Not used here, so: Line 1: Spec 0 ), Line 2: Spec 0.

Parm 13

todoitQpageIconOverride

null( "" )

Notice that we are creating a standard hyperlink in the two(2) menus, not using the todoItQpageIcon and todoItQpageIconAlt as described in the , primarily because they are already menus and don't need further explanation.

Not used here, so: Line 1: Spec null( "" ), Line 2: Spec null( "" ).

Parm 14

todoitQpageIconAltOverride

null( "" )

Parm 15

oneDebug

debug

debug and iam and iamCaller have been defined in and those definitions remain in effect for here.

Parm 16

iam

iam

debug and iam and iamCaller have been defined in and those definitions remain in effect for here.

Summary

In this setup we have done for you, we have completed our analysis of all the parameters and specs which were utilized to establish your index.html page as an alligator / crocodile demo. There is one more step in this section the kDisplay() script foot companion to the kDisplay() script head, but it is trivial and has nothing to do with the multiple contexts we've been discussing.

Upon review we do see that sometimes it appears that the more we explain the more complicated things appear to be. There are two reasons which immediately come to mind to explain this phenomena.

The first is that we have muddied the water. We certainly hope not but admit that that we do go off the deep end sometimes.

The second reason possible is that simply providing concise specs with no analysis of the interrelationship of the components, gives one a false impression of knowledge and understanding, and ironically upon clarification one begins to see complexity otherwise not seen.

Especially in a day and age of poke-n-peck, cut and paste, sound bites, and the infamous simple examples.

In the final analysis however we are certain that providing one study what we have written, he should learn much more and had we not written it.

We now proceed to the final step-by-step, in this section at least.

Examination of index.html: kDisplay() script Foot

Item

kDisplay()

Find

comment

< !-- Dimensions(tm), Scripts, kDisplay() Foot -- >

line

Bot

Note

There is one(1) line here ...

Line 1
No
Spaces

< script > kDisplay ( "head/foot" , "" , "" , "" , "" , 0 , "" , "" , debug , iamCaller ); < /script >

Line 3
Split
Out

< script >
kDisplay (
"head/foot"
, "" , "" , "" , "" , 0 , "" , "" , debug , iamCaller
);
< /script >

Format

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), under( _ )

Perfect

Must be letter perfect

Descript

Due to time constraints, this section of the manual has been delayed until all critical components have been completed.

But here are some quick notes:

kDisplay() ^script foot occurrence, the second of two occurrences of kDisplay() ^script, is required to integrate your web pages into the AEDOK Suitetm of Websites & Domains. It generates the proper footers for the various pages and maintains uniformity of style, as we have discussed.

kDisplay() ^script should be placed precisely at the location shown immediately before the end body, towit:
< script > kDisplay ( "head/foot ... debug , iamCaller ); < /script >
< /body >

and it does notgenerate an end body:
< /body >

You should add the end body: < /body >.

Possibly at a later date we will add an option to generate end body since we do generate the begin body. The reason we did not make it automatic is because one might have other statements he wishes to add before the end body.

The kDisplay() ^script line which we have shown as Line 1 No Spaces should have no spaces( ). We stretched and split it for easier reading.

Technically, all parameters are optional. If parm 1 is omitted it defaults to what is shown, because it detects that it has been called a second time, for the footers, towit:
head/foot

But we prefer to spec to eliminate uncertainty.

With the other parameters which are shown as null( "" ) or zero( 0 ), we prefer to spec as shown so that the positions are already laid out, should we need to activate various parms.

debug and iamCaller have been defined in previous steps and those definitions remain in effect for here.

Analysis

Discuss

Summary: Birds Eye View

Intro

In order to provide a bird's eye view of the forest ^{so to speak}, we now present a skeleton of your typical web page, with omitted portions indicated by ellipses( ... ) when that tag or reference is long.

The items are color coded using AEDOK standard color coding scheme repeated below for your convenience.

The column on the left links to the step in this step-by-step for full discussion of the item.

The column on the right indicates the maximum number of occurrences of the item. It is always either a single occurrence or multiple. occurrences at your discretion.

Note

Notice that each AEDOK script must be contained within the script tag pair < script > ... < /script > either as part of a group which begins with < script > and ends with < /script > (eg., the init ^group), or with its own tag pair ( such as for example kDisplay() ^script).

So in the specific case of todoitQ1() ^script, if one has multiple back-to-back references, the entire group of todoitQ1() ^script references may be enclosed within a single < script > ... < /script > pair, though for cut and paste purposes it is easier to cut and paste each one with its own pair.

Code

Color

Meaning

Normal

Normally generated by you or your web publishing software .

Required

You must copy, insert, duplicate, create or otherwise cause to be included (aka, insert).

Optional

You must insert if you elect to use the optional statement

Auto

Generated by Dimensions tm. Be careful not to duplicate.

Ref

Item

Meaning

Max

< html >

Beg standard HTML web page.

< title >

Beg title.

Your title

You provide title..

< /title >

End title.

< meta name= ...

Plethora of meta tags including important ones.

Multi

< link ... rel ... href ...
all_all__css_default.css ... >

AEDOK CSS style sheet.

< style >

html beg style tag

< /style >

html end style tag

< script >
... all/all_all__js.js">
< /script >

Beg script tag for javascripts.
AEDOK javascripts
End script tag for javascripts.

1
1
1

< script >

Beg script tag for init group

initFrame150801() ...

initFrame150801()

Multi

initLoad150801() ...

initLoad150801()

pakit() ...

pakit()

Multi

kClose() ...

kClose()

todoitQ2() ...

todoitQ2()

< /script >

End script tag for init group

< script >
kDisplay() ...
< /script >

Beg script tag for kDisplay head.
kDisplay()
End script tag for kDisplay head.

1
1
1

< body >

beg body tag

content

Your web page content, containing todoitQ1() references which replace traditional hyperlink references (next).

Multi

< script >
todoitQ1() ...
< /script >

Beg script tag for each todoitQ1.
todoitQ1()
End script tag for each todoitQ1.

Multi

content

content

Multi

< script >
kDisplay() ...
< /script >

Beg script tag for kDisplay foot.
kDisplay()
End script tag for kDisplay foot.

1
1
1

< /body >

end body

< /html >

End standard HTML web page.

End

FOOTNOTE: You are getting in at the ground floor. If you experience any difficulties whatsoever, and we make no pretense that you won't, contact us immediately via links at the bottoms if the pages, with the specs.

You are free to be as brief as you want, for intelligent people sometimes just a couple of words is all that is required to point out a problem. A blind man can see some of the problems for which some websites require a dissertation. But we appreciate any and all additional information or discussion you might want to share.

You will receive an a brief acknowledgement. Your issue will be placed on the front burner FIFO. The issue will be posted for all members to view and circumnavigate. And changes in the status of the issue will be posted as well as your being notified.

Thus it is hoped it each of us will enjoy the experience.

Examination of index.html: () script

Item Find comment // Dimensions(tm), Scripts, () line Note Format Form Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), under( _ ) Perfect Must be letter perfect Descript

Analysis

Discuss

Eg .

Std AEDOK color coding used below with regard to Requirements/Optionality is according the following selection:

Universally

Parm column: Dimensions tm, Thereafter: Specific Context.

specific context