AEDOK_Level_4_Active_Member_Website_Construction__Detail | How To Setup AEDOK Content Pages | Learn Scripting Techniques For Uniformity Of Web Pages

AEDOK Ktm Level 4 Active Member Website Construction Manual Detail

GENERAL OVERVIEW

This AEDOK Ktm Level 4 Active Member Website Construction Manual PAKITtm document is intended to be a single source document to guide an AEDOK Level 4 Active Member through the entire website construction process. As this is version 1, naturally it will change dramatically over time and we shall issue appropriate PAKITtm notifications.

It is important that one read it in its entirety from top to bottom. Though it need not be memorized, each individual component must be understood, otherwise chaos will most certainly insue as each individual web page must be properly integrated into the AEDOK Suitetm of Websites & Domains frameset structure.

Fortunately, the actual implementation process itself is not difficult as there are only about one half dozen steps required ^{per page} and AEDOK is extremely proud of the feat which we have accomplished.

On the other hand, this document itself is quite long since it is a single source document not broken into separate pages for the sections, and we desire to expound upon all the nuances, since at this point you know nothing of them.

If you read this document as though it were a letter written by a friend explaining something very exciting to him, this experience may be exciting to you too.

Though such a technique is certainly contrary to standard professional methods, with your help, we are creating a powerful educational tool, the AEDOK Suitetm of Websites & Domains, available to everyone throughout the world. That is certainly exciting on this end.

But of course, it is hoped that the implementation steps to be presented later should be sufficiently precise and concise as to allow one to implement his website without actually understanding the nuances of all the steps as partially revealed through the definitions and sometimes tedious discussions which are next. However, if and when something goes wrong, nothing takes the place of understanding.

As always, don't memorize, simply try to understand each individual step, each paragraph, each sentence. What ever one forgets is unimportant, because the comprehension he attains will later assist him in filling in the blanks.

Though the order of presentation presented here may not be the order inwhich you proceed in the implementation steps to be given later, this order is a ^{there may be others} logical order for a comprehension of the component parts and their interrelationships.

Introduction

As Steven Hawkings said, "Understanding is easy explaining is the hard part." Although we think we have done a thorough job of explaining, upon review, in part because we have been so thorough in our explanations even tedious, it is sometimes difficult to see the proverbial forest for the trees.

But since there are truly only half a dozen concepts around which everything else revolves, we will briefly explain some of them here and then you can see that all the detail simply discusses the connections, the mechanics, and the glue, and thereby hopefully be able to read it and digest it more thoroughly.

Your Home Directory

A Frameset

A Frame

A Page

Your home directory is specified by what we call initTopSub.

A frameset is a specific kind of page that helps to break up the general overall viewing area into blocks which can be independently manipulated. There can be numerous framesets which can be located in your home directory, our directories, or another member's home directory. Of course they can be located in other directories but that gets us into the tedious details, and to make them easier to find we prefer to place them in home directories.

In the AEDOK Suitetm of Websites & Domains, the first part of the name of a frameset is the home directory in which it is located.

A frame is one of those display blocks mentioned in frameset and it's only home is a specific frameset.

Finally, a page is always displayed in some frame of a frameset in some directory, but has its own address which could be anywhere, and which might be specified as being relative to either the current page that is referencing it, or relative to the frameset in which it is to be displayed.

Just about everything else is, as stated above, the connections, the mechanics, and the glue.

Display Techniques

Overview

Color coding the importance of a specification is an interesting concept. As we shall often point out, there are entire dimensions of communication ^{not just "levels"} that need to be explored and expressed. generally we attempt to be compliant with the Western conventions of green yellow red, put broadly as a range from safe threw caution to danger (and then any number of variations thereupon), but it is difficult, yea impossible, to map the universe into the rainbow.

So the following techniques though somewhat "flat" in their ability to express the true depth of the interactions of the components, will hopefully suffice to get us off-the-ground.

In this particular context of parameters of scripts,there are two(2) concepts, towit: Whether a parameter, because it is a place holder, must be specified even if zero or null, and whether a parameter, once specified, needs to have a non-zero or non-null value ^{as the situation requires}. We shall attempt to integrate this complicated form of optional into our color coding.

Something required is indicated thus.
In the general context, it could be anything. Specifically, in the case of scripts, it could be the entire script, or for just a parimeter.

Something optional is indicated thus.
In the general context, these two(2) concepts (required and optional) stand alone. Specifically, in the case of scripts, there can not be a required parameter after an optional parameter. And anything that is not indicated as an optional parameter is a required parameter regardless of other coding indications or values it may have, even if it is only required as a place holder.

Something required (as a place holder) but has some aspect of optional is indicated thus.
In the general context, an example might be a requirement of an acknowledgement without a requirement of a specific commitment. Specifically, in the case of scripts, a required parameter may still have an optional value. That is to say, a value of zero or null would be as though the parameter were an optional parameter were it not required as a place holder. But note that there are some parameters that have zero as a distinct meaning. It is not an optional value simply because it may have a zero or null value as one of it's meanings and specifications.

However, there is yet another wrinkle. An optional value, once it has been specified, may itself place requirements upon other parameters which in these specifications might then be inappropriately marked. So in other words, one must be keenly aware of the functionality of the parameter and not rely exclusively upon our indications.

Something required (as a place holder) but otherwise is unnecessary or ignored thus.
In the general context, an example might be "this page intentionally left blank". Specifically, in the case of scripts, an unnecessary parameter would be one that is ignored by the script, except that it is required as a place holder.

Something important is indicated thus. or thus.
In the general context, it could be anything. Specifically, in the case of scripts, a parameter who's values have important implications and ramifications. The results will not simply be cosmetic.

Something critical is indicated thus.
In the general context, it could be anything. Specifically, in the case of scripts, a parameter who's value just has to be right or things just won't work. That is to say, even though it is a variable in the script and may have countless otherwise valid values, in your situation and context, there is really only one right value.

Something cautionary or illusive is indicated thus.
In the general context, it could be anything. Specifically, in the case of scripts, a parameter who's value may range all the way from optional value to critical. This is because in some circumstances they are not needed, but in other circumstances they may be needed and even be critical.

Something we forgot to do is indicated thus.
This text, though correct, has some aspect associated with it, possibly a hyperlink, that we forgot to or have not gotten around to doing. Writing at AEDOK is a very dynamic situation. Things reference other things more than at a standard website as a primitive attempt to add more dimenions to the content. We say primitive because it is using current techniques which themselves are not part of a truely organized larger context. Only fragments,... ideas. Our mission is to rectify this 19th Century perspective. Until then, we shall utilize them to the best of our ability.

Summary

Even though something required (which is supposed to be orange) might seem more important than something important or something else important and therefore perhaps it should be red instead, in general there are more ( quantity wise ) important things than required things, and traditionally red is used to indicate important. Of course red also used to indicate required. Like we said, it's difficult to map the universe into the rainbow.

Color coding is once again presented, here without narration.

Something required is indicated thus.

Something optional is indicated thus.

Something required but has some aspect of optional is indicated thus.

Something important is indicated thus. or thus.

Something critical is indicated thus.

Something cautionary or illusive is indicated thus.

Something we forgot to do is indicated thus. Please contct us if you see anything marke in this fashon.

DefinitionsCommon and AEDOK

DEFINITION OVERVIEW

AEDOK attempts to use common definitions as precisely as possible and then establish new definitions for our variations. There is nothing remarkable about this, but accordingly, the following itemization is a combination.

This is not a complete list of AEDOK definitions and but a grain of sand on the beach vis-á-vis the world. One of our ^planned projects is to assemble as many definitions as possible. Of course, others have done this. It is called a dictionary. And there are great dictionaries given 19th century technology. But again, as is a common theme, the representations of the interactions of the words, terms and phrases is so shallow.

The representaions to be presented here are no better, but they suit the purposes. In particular, the definitions presented here of commonly accepted terms are often incomplete ^{though hopefully correct as far as they go} as we are not giving a lesson on the terms themselves, but rather, intend to clearly elucidate the distinction between certain commonly accepted terms and AEDOK introduced terminology.

Nomenclature

All terms are case-insensitive. In usage here, a term may have upper case letters to separate words without spaces or underlines. There is no hidden meaning in the capitalization. Two(2) terms one with a capitalization and the other without but otherwise identical would have the same meaning. Thus:

commonPractice
commonpractice

Later in the discussion and usage of the scripts, all scripts, names and variables are case-sensitive and must use the case as specified. However, even then we do not hide meaning behind such arbitrary techniques like this:

aSneakyScript();
aSneakyscript();

the above two references being to two(2) different scripts.

All examples assume, and it is a technique to which we adhere rigorously, that for any given subdomain there is a directory of the same name as the subdomain, under the domain in a mirrored structure, thus:

subDomain directory
edu.aedok.org aedok.org/edu/
yourSubdomain.edu.aedok.org aedok.org/edu/yourSubdomain/

However, because it is possible for the host ^{that would be us} to point a sub domain to anywhere of choice, one cannot be certain other websites maintain this similar structure, though it is common.

AEDOK uses both the words content and context. Notice that there is only one letter difference in the spelling, but the meanings are quite different from one another and in many sentences, grammatically either word could be used. Be sure to read carefully.

Term (common usage)

fullDomain, aka the complete domain

Definition

As universally accepted. The entire domain specification (in a given context).

Discussion

Notice we say, "in a given context". That is because the fullDomain is not actually a thing unto itself. The word "full" is an a contextual adjective, as apposed to top which as also an ive, but not contextual.

Consider the example below. You have pages under yourSubSubDomain.edu.aedok.org. But we have pages under edu.aedok.org. In your context and our context, the topDomain is the same, ie., org. But the fullDomains are not the same. In your context, the fullDomain is yourSubSubDomain.edu.aedok.org, whereas in our context, the fullDomain is edu.aedok.org.

Example(s)

edu.aedok.org
yourSubSubDomain.edu.aedok.org

Term (common usage)

top, aka topDomain

Definition

As universally accepted. The first level of a domain specification.

Discussion

Example(s)

com
net
org

Term (common usage)

dom, aka domain

Definition

As universally accepted. The second level of a domain specification.

Discussion

Example(s)

aedok

Note:

The term dom has other meanings not discussed here.

Term (common usage)

sub, aka subDomain

Definition

As universally accepted. The third level of a domain specification.

Discussion

In normal usage, sub might also include fourth and fifth levels ^etc. In these discussions, we restrict sub to mean third level, and introduce additional terms below for subsequent levels.

Example(s)

edu as in edu.aedok.org
ent as in ent.aedok.net

Term (common usage)

subSub, aka suSubDomain

Definition

The fourth level of a domain specification. And the second level of a subDomain specification.

Discussion

See subDomainDepth below.

Example(s)

yourSubDomain.edu.aedok.org
yourSubDomain.ent.aedok.net

Term (common usage)

subSubSub, aka subSubSubDomain

Definition

The fifth level of a domain specification. And the third level of a subDomain specification.

Discussion

See subDomainDepth below.

Example(s)

yourSubDomain.qqq.edu.aedok.org
yourSubDomain.qqq.ent.aedok.net

Term (aedok usage)

subDomainLevel aka level

Definition

The subDomainLevel is the same as the concept of level used in the above definitions, towit: top, dom, sub, et al. Of course, the level varies accordingly.

Discussion

subDomainLevel is based on a 1 origin, positive only, system, with respect to top. Ie., the first level is level 1, there is no level 0, nor negative levels.

We distinguish between subDomainLevel and subDomainDepth ^{defined next}.

Example(s)

level domain spec
1 com
2 aedok.net
3 edu.aedok.org
4 yourSubDomain.edu.aedok.org
4 yourSubDomain.ent.aedok.net
4 qqq.edu.aedok.org
4 qqq.ent.aedok.net
5 yourSubDomain.qqq.edu.aedok.org
5 yourSubDomain.qqq.ent.aedok.net

Term (aedok usage)

subDomainDepth, aka depth

Definition

The subDomainDepth is the subDomainLevel minus two(2).

Discussion

subDomainDepth is based on a 1 origin, positive only, system with respect to sub. Ie., the first depth is depth 1, there is no depth 0, (except on an instantaneous basis to loop around the highest boundaries), nor negative depths.

Another way of looking at it, is that the depth is the level of a sub domain, but we use two different words to emphasize the distinction between these two types of levels, subDomainLevel and subDomainDepth.

This is a critical, but not necessarily difficult, concept. AEDOK scripts need to know the subDomainDepth for proper generation of internal cross-domain linkages. Note that because there is no zero or negative depth, in this context dom and top have no depth. The scripts never refer to the depth of dom or top.

Example(s)

depth level domain spec
~ 1 com
~ 2 aedok.net
1 3 edu.aedok.org
2 4 yourSubDomain.edu.aedok.org
2 4 yourSubDomain.ent.aedok.net
2 4 qqq.edu.aedok.org
2 4 qqq.ent.aedok.net
3 5 yourSubDomain.qqq.edu.aedok.org
3 5 yourSubDomain.qqq.ent.aedok.net

Summary:

These two(2) critical terms, level ^{subDomainLevel} and depth ^{subDomainDepth}, are easy to ascertain. To determine the Level simply count the number of pieces of the fullDomain. To determine the depth, subtract two(2), or count from the subDomain.

Term (common usage)

absolute address, aka absolute url

Definition

As universally accepted.

Discussion

An absolute address by it's nature, unambiguously specifies the location of a page. Compare to relative address below next.

Syntax ^incomplete

http://

Example(s)

http://aedok.org
http://edu.aedok.org
http://yourDomain.edu.aedok.org
http://yourDomain.edu.aedok.org/yourPage1_of_theSubDomainRootDirectory.html
http://yourDomain.edu.aedok.org/yourDirectory1/yourPage1_of_yourDirectory1.html

Term (common usage)

relative address aka relative url

Definition

As universally accepted.

Discussion

A relative address is a means (sometimes convenient sometimes essential) for specifying a page relative to the page containing the specification.

It is convenient, in that given a directory structure, one may specify a page by moving up and down that structure without having to specify the full absolute address path.

It is essential, in that an absolute address for the host system ^{the Internet}, wouldn't exist on a local system. Eg., your developmental copy of your website. Further, given two(2) arbitrary local systems ^{ie not the host (AEDOK)}, your complete website may be situated in directories having different paths. Eg., your office and your home,

Example(s)

aedok

http://yourSubDomain.edu.aedok.org/yourDirectory1/yourPage1_of_yourDirectory1.html

http://yourSubDomain.edu.aedok.org/yourDirectory1/yourPage2_of_yourDirectory1.html

http://yourSubDomain.edu.aedok.org/yourDirectory2/yourPage1_of_yourDirectory2.html

office

(c):/companyName/aDivision/web/public_html/yourSubDomain/yourDirectory1/yourPage1_of_yourDirectory1.html

(c):/companyName/aDivision/web/public_html/yourSubDomain/yourDirectory1/yourPage2_of_yourDirectory1.html

(c):/companyName/aDivision/web/public_html/yourSubDomain/yourDirectory2/yourPage1_of_yourDirectory2.html

home

(c):/myfiles/projects/experimental/aedok/yourSubDomain/yourDirectory1/yourPage1_of_yourDirectory1.html

(c):/myfiles/projects/experimental/aedok/yourSubDomain/yourDirectory1/yourPage2_of_yourDirectory1.html

(c):/myfiles/projects/experimental/aedok/yourSubDomain/yourDirectory2/yourPage1_of_yourDirectory2.html

Analysis

Given the above example, on each computer system, from the first page (yourPage1_of_yourDirectory1.html) you could reference the second and third pages all the same way, thus:

FROM	TO	SPEC
yourPage1_of_yourDirectory1.html	yourPage2_of_yourDirectory1.html	yourPage2_of_yourDirectory1.html
yourPage1_of_yourDirectory1.html	yourPage1_of_yourDirectory2.html	../yourDirectory2/yourPage1_of_yourDirectory2.html

Whereas, with absolute addressing you would have to write some extremely complex and tedious scripts to convert the addresses.

Term (aedok usage)

backaround relative address, aka

Definition

The backaround relative address is a specific variation on the common relative address. It is the address required to to back up the directory structure, and then go forward down the directory structure to the destination ^desired page. It is composed of three(3) parts, towit:

backup relative address component
forward directory specification component
desired page.

Discussion

We've given the backaround relative address a separate name because not all relative addresses back up, and some only back up and we need to be able to isolate that group that do both in our discussions simply for a clearer understanding of where everything is located, and how the various pieces interact.

The backaround relative address can't take you anywhere that therelative address can't, because it is a relative address. Our point is, that a standard relative address that goes only forward, could backup and thus be a backaround relative address, it just wouldn't be the shortest path. By studying the backaround relative address, one may gain a better perspective that the domain in which he is operating is part of a larger picture.

Example(s)

relative address IS IT A backaround relative address? Why?
dir1/aPage.html No It goes only forward
../anotherPage.html No It goes only backward
../dir2/aThirdPage.html Yes It goes back and then forward

Term (aedok usage)

backup relative address component, aka

Definition

The backup relative address component is the first of three(3) parts of the backaround relative address ^{defined above}. It is the number of dotDotSlash(../) sequences required to back up before one can then proceed forward again, (using the forward directory specification component ^{defined next}) to get from where you are ^{one page}to where you're going ^{another page}.

Syntax

../

1 ../
2 ../../
3 ../../../
etc

Discussion

If the destination page, is in a different directory not contained deeper within the current directory, or indeed if the destination page is in a different subdomain, one cannot simply specify that directory or subdomain followed by the page name. If he did, said directory and or subdomain would be interpreted as subdirectories of the current directory. One must therefore back up to the directory which contains the different directory or subdomain, so that they are correctly interpreted as subdirectories of that directory (in which they are actually found), after which the page is then located.

Each sequence of dotDotSlash(../) backs up one directory. We call that entire backup sequence the backup relative address component.

One then specifies the complete and necessary sequence of directories to get to the destination page. We call that complete forward sequence the forward directory specification component. Followed by the destination page ^{which doesn't need a special name}.

Example(s)

../all/all_all__js.js

In the above example, we back up one directory and then go forward one directory, all, and then specify the destination page, all_all__js.js.

(aedok usage)

forward directory component, aka

Definition

The forward directory component is the second of three(3) parts of the backaround relative address ^{defined above}. It is the directories required to go forward down after one has backed up (using the backup relative address component ^{defined above}) to get from where you are ^{one page}to where you're going ^{another page}.

Syntax

directory slash(/) directory slash(/) ..

Discussion

See discussion for backup relative address component ^{defined above}.

Example(s)

See Example(s) for backup relative address component ^{defined above}.

Term (aedok usage)

cross subdomain relative addressing, aka

Definition

Crossing from one subdomain to another using relative addresses rather than absolute addresses.

Syntax

Discussion

See discussion for backaround relative addressdefined above.

Example(s)

See Example(s) for backup relative address component ^{defined above}.

Term (aedok usage)

page-relative address, aka

Definition

A page-relative address is a relative address ^{defined above} with respect to the page in which the relative address is specified.

Discussion

When one references a page from a hyperlink with the intent to load that page, he must not only know where the referenced page is located, but he must also know where the referencing page is located. Once one knows both, then and only then can he figure out what it takes to get from where he is to where he is going. That is the page-relative address.

Common usage is to use the term relative address followed by the phrase with respect to this-or-that. Or to use the term relative address and assume the phrase with respect to this-or-that is understood.

In these discussions and documentation, AEDOK uses four(4) distinctly different with respect to ... phrases, as follow:

with respect to the page containing the hyperlink,

with respect to the frameset into which the page is to be loaded ^displayed,

with respect to a single specific fixed location within the AEDOK domain structure,

with respect to a specific subdomain within the AEDOK Suitetm of Websites & Domains.

But there is a tendency to overlook such phrases as, with respect to, or at least a possibility of overlooking them, or even if they are not overlooked, not remember them at a later time, or not remember clearly with respect to what. So we simply put this important information in the term itself, thus: page-relative address, frameset-relative address, domain-relative address, and subdomain-relative address.

So, page-relative address is the usual reference used in a standard hyperlink reference, the relative address.

But continuing now with this discussion, in the AEDOK Suitetm of Websites & Domains, one replaces the specific hyperlink reference with the todoitQtm script references ^{defined later}, in order to facilitate the todoitQtm and the spawntm controls.

Example(s)

Term (aedok usage)

frameset-relative address, aka

Definition

A frameset-relative address is a relative address ^{defined above} with respect to the frameset into which the page it is to be loaded ^displayed.

Discussion

Read page-relative address ^above discussion first.

The usual usage of this term is in the case of a single page request ^{defined below}, such as from a search engine or a bookmark. In such cases, the author must decide ahead of time in which frame of which frameset said page should be presented along with any other supporting pages, thereby pulling the surfer into its context.

It is the frameset that needs to know where the page is located, not the other way around. So in the init() ^{define later} spec the frameset-relative address is used showing the relationship of the page being established to the frameset in which it is to be loaded.

Consider: To the author said page might itself be a lesser supporting page to another page or pages. But at this particular instance, to the surfer it is the center of attention. Very often, the documents it was supporting now support it. So it's current location is the center of attention, in usually a larger frame than the author would normally present it, and the documents it was supporting are now off to the side available for the surfer to become involved.

Example(s)

var iam="../all/all_all__K(tm)_anecdote_snail-mail_clutter.html"; var iamCaller="";

var spr=iam;

initLoad150801(

"org_AEDOK", "f_single-page-request_main-clf_ala_com.html", "f_SE_content", iam, iam, 0, "about", "Snail Mail Clutter and the AEDOK Mission", "K(tm)", "3", "~", "Deadend", debug , "");

In the above example, Snail Mail Clutter and the AEDOK Mission is merely a descriptive name of the page referred to in a link from the AEDOK.com about us ^{not shown} introduction, About AEDOK Mission, and would normally appear in Ktm's window ^f_main_admat the top of the screen ^{by a spec not shown}. The actual name of the page we are discussing is found in the script variable iam and is all_all__K(tm)_anecdote_snail-mail_clutter.html. However, if a surfer has clicked or linked to this page, because it is an interesting anecdote we want to display it prominently in the content window ^f_SE_content, the forth parm. In the primary window ^f_SE_primary, which is smaller we place the <'i>About AEDOK Mission page itself. This is not shown because the frameset itself, f_single-page-request_main-clf_ala_com.html ^{third parm} has that information. In between it and the snail mail story in the secondary window ^{f_SE_secondary}, which is larger than the primary and smaller than the content windows, we place the Member Levels Intro .This is also not shown because the frameset has that information.

So with absolutely no clicking or searching on the surface part, he has immediately before him our mission, and all he needs to know about becoming a member.

One of the beauties of this is, among other things, that any number of arbitrary pages can reference this pre-established frameset. The author decides where in this frameset the individual page should appear. And the frameset, being pre-established, fills in the blanks.

That, if we do say so ourselves, is powerful.

You, the AEDOK Level 4 Active Member, may establish any number of these pre-established framesets since all they are is web pages, to place your various content in the most appealing context when the surfer has already made it his center of attention.

Further, you may also use not only any AEDOK framesets, but any frameset established by any other member. All you need do is reference them. No modification is required, so there's no possibility of interfering with the other members website. Naturally, those members will have established pages in their frameset which are of no interest to you. What is important is that if the frameset structure is itself appealing, then you can load whatever other pages you want into the various frames of that other member's frameset, utilizing the companion to the above initLoad150801() script. The companion is initFrame150801(). One need only specify a single initFrame150801() script per frame. And you simply leave the header ^{AEDOK logo} and footer ^{AEDOK copyright} frames alone.

The complete details are presented in the instructions ^later.

Term (aedok usage)

domain-relative address, aka AEDOK relative address

Definition

A domain-relative address is a relative address with respect to a single specific fixed location within the AEDOK domain structure.

Discussion

Read page-relative address ^above discussion first.

That single specific fixed location is, level 2 which is depth 0 . But that is the reference point, so the highest domain-relative address is actualy at level 3 which is depth 1

This terminology allows one to see exactly where within the AEDOK Suitetm of Websites & Domains a page resides.

Example(s)

The following domain-relative addresses are all at level 3 which is depth 1

all/all_all__js.js

all/all_all__about_mission__intro.html

all/all_all__K(tm)_anecdote_snail-mail_clutter.html

all/all_all__member_levels__intro.html

com/pf/com_pf__prod_recipe_persimmon_syrup_oatmeal_1_cereal.html

org/edu/yourSubSubDomain/mainPage.html

More Discussion

The domain-relative address always gets one to the same location as the relative address, and vice versa. But the domain-relative address shows a more complete path.

Whereas the relative address shows the path from the current location to the destination, the domain-relative address also shows the path from level 3 which is depth 1. When dealing with multiple subdomains, from a developmental perspective, it is often useful to see not only how to get from where you are to where you are going, but also, where "where you are going" really is.

In dealing with a single subdomain, an AEDOK Level 4 Active Member might be more comfortable using standard relative addresses, and indeed, one's web publishing package likely uses them.

However, in any reference to any of the AEDOK standard pages or functionalities or any page from another Level 4 Active Member, which should be in another subdomain (such as for example a frameset), the domain-relative address would be the same as the relative address in order to get around the inherent subdomain boundaries.

Term (aedok usage)

subdomain-relative address, aka

Definition

A subdomain-relative address is a relative address with respect to a specific subdomain within the AEDOK Suitetm of Websites & Domains.

Discussion

That specific specific subdomain is usually the AEDOK Level 4 Active Member's own subdomain.

Example(s)

knowItAll.edu.aedok.org IS LOCATED IN org/edu/knowItAll/
sub-domain-relative address domain-relative address
index.html org/edu/knowItAll/index.html
books/great_thougts.html org/edu/knowItAll/books/great_thougts.html

Term (common usage)

frame, aka window

Definition

As universally accepted. A fixed ^supposedly rectangular area of the browser window into which a page may be loaded from a hyperlink reference without disturbing the content or appearance of the remainder of the browser window which contains other frames.

Syntax

Discussion

See discussion of frameset ^{defined below after target}.

Example

Analysis

Caveat

Notice we say, "A fixed supposedly ...", for we have discovered, much to our horror, that some mobile device browsers do not respect frame boundaries, and apparently expand them at will and unpredicatably. Thus creating an extremely difficult navigational experience on what is already a small display area.

Summary

The aka window terminology is only used in casual reference such as "Go to the window to the left and tell me what you see." In all descriptive, instructional, educational, or technical references one generally uses the proper term frame, though we sometimes use both terms to give a larger context to the narration.

Term (common usage)

target, aka

Definition

As universally accepted. The frame ^{defined above} into which a page is to be loaded and displayed.

Syntax

Discussion

See discussion of frame ^{defined above}.

Example

Analysis

Caveat

Summary

Term(common usage)

frameset, aka

Definition

As universally accepted. A page which specifies a group of frames.

Framesets can be nested. So a frame can contain a page which is itself a frameset.

Syntax

Discussion

Most websites attempt to use them innocuously, with no or as little indication of their presence as possible. This can produce a very smooth and appealing experience. Of course, they also use tables (again, often hidden with no apparent borders) to partition and cordon off areas.

These techniques of concealment of the skeleton ^{so to speak} allow one to structure and utilize the available display space efficiently according to a design and plan. However at AEDOK we desire to clearly show the juxtapositioning relationships of the components, in that it adds a dimension to our presentations. So, we display the structure itself a little more prominently, including even scroll bars to the individual pages (in addition to the normal browser scroll bar). It is a matter of the ambiance one desires to create.

Example

Analysis

See single page request ^{defined next}

Caveat

Summary

(aedok usage)

single page request, aka

Definition

A surfer's clicking on a single web page from, say a search engine or book mark, as compared to a click to a complete website, via say entering HTTP://example.com, and as compared to a click from within your website. Even though the click from within your website is for a single page, we do not use the term to refer to that kind of reference. From within your website is is simply a reference or hyperlink reference or click or mouseover.

The single page request is the action by a surfer that results in the action by the website commonly referred to as self locating ^{defined next}.

Syntax

Discussion

For a complete discussion and analysis, continue reading until you get to contextually self locating.

Example

Analysis

Caveat

Summary

Term(common usage)

self locating, aka self location

Definition

The ability of a web page to automatically load an entire website or a frameset thereof, thus creating a larger context than simply the single page.

Syntax

Discussion

By the website's utilization of self location, or self locating pages, when a surfer clicks on a page, say from a search engine or book mark, he gets the entire website not just that page.
For a complete discussion and analysis, see contextually self locating ^{defined next}.

Example

Analysis

Caveat

Summary

Term(aedok usage)

contextually self locating, aka contextual self location

Definition

The ability of a web page to go a step further than self locating ^{defined above} and loading additional information, pages, or frames which help to establish the context in which the original page ^{the single page request} was originally designed for and intended to be found or located in.

Syntax

Discussion

Consider: There may be pictures or other discussion, foot notes, or reference material that, in a manor of speaking, belongs with the page.

Though self location is becoming common, contextual self location is a bit more complex, as one can not just load the page into a hodge-podge setting, but rather, must examine and understand the page and it's contextual requirements.

All pages in the AEDOK Suitetm of Websites & Domains are intended to be contextually self locating. For example, If you are viewing this page because you found it in a search or bookmark, then you are viewing it in the largest AEDOK content window ^frame toward the right-center of your screen, whereas, if you are viewing this page as a result of a click from within the AEDOK Suitetm of Websites & Domains, you are most likely viewing it in one of the smaller, narrower windows ^frames to the left of the content window ^frame, designed just for viewing such things as, menus, lists, definitions, terms, and briefer explanations or even discussion such as this, without covering the page that referenced it.

Example

Analysis

Now, under normal circumstances the surfer navigates to your website. Upon arrival, he either gets a single page with numerous links (usually a list at the top and/or a list at the bottom) for access to the entire website, or a frameset which has numerous pages which themselves have appropriate links. At your website when he clicks on one of your links, whether it be from within a page or from a menu, you can cause the specific page which is about to be loaded to load into a specific frame of the frameset, called the target ^{defined above}, allowing you to control the positioning of the content of the page to be loaded, which therefore shapes your website appearance.

Anyone, that is, any website, can do that. But what happens in the case of a single page request? Not from a link within your website, we have just discussed that. What happens when a surfer outside your website request an arbitrary page, usually from a search engine or a bookmark? How does he get the context you intended for that page which may be quite different from the context of another arbitrary page from your website?

That is what we will be discussing here. The single page request from outside your website, because we already know you can control the content he sees once he gets to your complete website by his clicking on your various links.

In a simple situation, he would get the single page he requested which has links at the top or the bottom from which he can then navigate to your complete website (as we mentioned above). This in fact is great for mobile devices since the screens are relatively small to begin with.

But what if that page actually belongs in a larger context? Say for example, associated with that page is a list. Not necessarily a menu, per se., possibly you are selling nicknacks. You have a list of nicknacks which have common characteristics. Possibly they're all of the same material, ivory, bone, quartz. Possibly they are of a similar style, say for example pictures of dogs. It is to your advantage to have that list displayed on the screen without requiring the viewer to click another link or enter a search. He's already interested in dogs. Why have him search for dogs? You might have both dog statues and dog pictures. But he has already clicked on a page of a dog picture. Your page. This is the page that brought him to your website. He has already focused his attention on this page.

Seize the moment. It is to your advantage to have that list, not another list that he has to search for, already in front of him. It is to your advantage to have other things related to that specific page already in front of him. Pricing options, membership options. Not just a link to become a member that he'd have to click on should he decide he's interested, but a full list of reasons why he should become a member already placed in front of him. It is much more convenient for him.

Now, the above was discussing nicknacks, but the same reasoning applies to whatever it is you are peddling. Even information such as at AEDOK. In fact, even more so. If the surfer is looking for a picture of a basset hound, he may settle on a collie. But if he is looking for information on an HTML tag, he is not really interest in a PHP echo command.

Here's the point. Although we are accustomed to going through all these extra motions, that is only because it is the way everyone else does it! But in fact, it is not a great idea. It is actually frustrating to have to search for something twice, three times, especially when the second and third searches don't turn out the same results of the first! You search once at the search engine, you find what you think you're looking for, you click the link, and then you have to look for the search box to search again. Then you have to go through all sorts of options just to get to where you already thought you were going. And when you do get somewhere, is highly unlikely you get the page or specific information that brought you to website in the first place. You'll have to look for it. Sure, we do it all the time. Constantly being diverted, frustrated, slapped in the face, poked and prodded. But it is not a good way to do things.

So our surfer has already done the search, has clicked on the link, and that link has taken him to your dog picture.

Now unless you have dynamic page generation software to generate these pages we've been talking about, the technique you would use to establish the proper context for that page would be to have a specific frameset designed for that specific page.

Let us discuss the nature of these framesets and then we will come back to, "what if ...".

Different framesets can contain frames of the same name, vis-á-vis one another, providing they are not both used at the same time. Accordingly, one may have numerous framesets that have the same appearance structurally, but which have different predefined sets of content. waiting to be loaded

This allows one to specify a unique context, for a specific page, by establishing a unique frameset page for said page, and thus have the same general appearance of the website, yet specific content unique to that page. This is relatively easy to do, but it requires twice as many pages. The next step however is more difficult.

Now, these frameset characteristics also allow one to specify the same context, for one or more pages in a group, by specifying that each of these pages in said group utilize this common frameset vis-á-vis a separate frameset per page.

So, if for example you had a dozen pages though it could be any number, and you didn't want two dozen, you could have each one automatically point to, or link to, a common frame set. But then you would lose the uniqueness of the individual 12 pages.

But the facilities you have available to you as an AEDOK Level 4 Active Member can accomplish this without losing the uniqueness of the individual 12 pages via a AEDOK proprietary techniques.

The implications are somewhat dramatic in that it allows one to specify a general context for a group of pages (that would normally have the same general context anyway), and of course different from another group, but containing the individual page that the user originally requested, without having to specify a frameset page for each page in that group.

Bear in mind, that websites which possess sophisticated dynamic page generation software to generate web pages based on say for example a user search request (once he has arrived at the website), can accomplish this. And such technique is in a manner of speaking, more sophisticated than what we are doing here at AEDOK.

On the other hand, it is highly unlikely that they have the capability of taking your pre assembled web pages, whether they be produced by web publishing software or whether you create them by hand, and insert them into group context specific framesets resulting in a unique context appearance, the experience, as we are here discussing and have achieved at AEDOK.

Now let's go back to our "what if ...".

We need a frameset which contains your list (not the list at the search engine) and these other things we were discussing: rates and reasons to become a member, or discount structures, or whatever is appropriate. Possibly a list of satisfied customers and their testimonials. Another page possibly your credentials. The testimonials and credentials pages could be common to all your pages in these single page request situations. After he has arrived and is navigating thru your website those pages might be over laid to utilize the visual space but they could then be accessed thru menu selections.

But initially when the user arrives at this page, directly from the single page request, It automatically loads the frameset to load this appropriate context without his having to click on your testimonials and your credentials, or locate the specific page that brought him to you website in the first place. And without your having to create a separate frameset page for each and every page and therefore twice as many pages.

But this is a common frameset, and any page that uses this frameset to load itself, will get only the common pages specified in this frameset plus itself.

We have taken it even one step further.

For each of these pages we've been discussing in this group that reference this common frameset, you can specify that additional frames within the frameset, can have their content replaced with specific pages. Pages specific to this specific page. Pages that override the content in any frame already loaded by the common pages but required by the specific pages.

So these would be in addition to the common pages (testimonials and credentials pages), page specific associated pages like lists, documentation, references, and citations unique to this specific page.

So now when the user arrives at this page it automatically loads the frameset to load this appropriate context without his having to click on your testimonials and your credentials, or his having to click on the page specific associated pages (lists, documentation, references, citations) which he would not know to click on anyway. And still without your having to create a separate frameset page for each and every page and therefore twice as many pages.

This is accomplished with no more than a single intFrame YYMMDD() script per frame to be reestablished.

These additional scripts are placed in the page requiring the support pages, not in the support pages themselves. In this way, every page concerns itself only with ^figuratively it's own world and what it needs, so there is no possibility of inadvertent modifications to already established, functional pages

Now at this point, we need a fairly detailed example to clearly show the power of just this one feature of the AEDOK Dimensions tm v 1.0 Web Publishing Platform.

This example should be as easily applicable to an auto mechanic comparing makes and models of various vehicles, their components , or of machinery, or to a cook comparing recipes, or to a hobiest comparing various models, as it is applicable to a botanist, but we shall use frogs.

Suppose you are utilizing our preestablished org_AEDOK__f_single-page-request_main-clf_ala_com.html frameset which contains the following frames:

FRAMESET optional

org_AEDOK__f_single-page-request_main-clf_ala_com.html
Name Purpose Location Status
f_main_head AEDOK Logo AND Your Logo Top Left Restricted
f_main_adm Ktm's window. Briefer explanations. Top Right Use It
f_main_info Ques, Advertisements Far Left Restricted

f_main_work
org_AEDOK__f_single-page-request_SE-clf_ala_com.html
Main Display Area Use It
f_main_back Background activities, Then refreshed with AEDOK Logo Hidden Rstricted
f_main_foot Copyright, et al. Bottom Restricted
Note:
f_main_work is always for main display OR additional framesets. The frameset in this table, org_AEDOK__f_single-page-request_main-clf_ala_com, uses it for the additional ^sub frameset org_AEDOK__f_single-page-request_SE-clf_ala_com. These two(2) nested framesets are the framesets being used for this presentation, and this page is most likely in f_SE_content, but possibly one(1) frame to the left of f_SE_content in f_SE_secondary, both frames being part of said additional-sub-frameset, here loaded into f_main_work and shown below in the next table.

FRAMESET optional

org_AEDOK__f_single-page-request_SE-clf_ala_com.html
Name Purpose Location Status
f_SE_promo AEDOK Promotions Under Logo Restricted
f_SE_user_head User Control Icon Menu for User Controls To Right of Promotions Restricted
f_SE_user User Controls. To Right of User Control Icon Menu Restricted
f_SE_primary_head First Level Menu Icon Controls To Right Of Info, Above Primary Use It
f_SE_primary First Level Menu or Selection Area To Right Of Info, Below Primary Head Use It
f_SE_primary_work First Level Work Area Below Primary toward Bottom Use It (resize)
f_SE_primary_foot First Level Like a Background Below Primary at Bottom Use It (hidden)
f_SE_secondary_head Second Level Menu Icon Controls To Right Of Primary, Above Secondary Use It
f_SE_secondary Second Level Menu or Selection Area To Right Of Primary, Below Secondary Head Use It
f_SE_secondary_work Second Level Work Area Below Secondary toward Bottom Use It (resize)
f_SE_content_head Content Level Menu Icon Controls Below Secondary at Bottom Use It
f_SE_content Content MAIN VIEWING AREA Most Of Screen Use It
f_SE_content_work Content Like a Background Below Content at Bottom Use It (resize)
Frameset names and propose are only for general reference. The resize are designed for development as pages and programs can write tracing information generated above them, or one can launch ongoing activities into them. They are defined as very small, but can be resized upword by grabbing and stretching. One can turn off their access to user using noresize in frame tag.

In the dynamic situation, where the user is already at your website, suppose you are comparing the anatomy of the bullfrog to other critters. This example begins after the user has already selected and you have already displayed a bullfrog overview as follows:

You are utilizing three(3) frames in our preestablished framesets:f_SE_primary ^primary, f_SE_secondary ^secondary, and f_SE_content ^content. A general overview of the bullfrog is currently displayed in the content frame which is the right most and largest. In the primary frame which is leftmost and smallest of the three(3) you have displayed in list of critters to which you have compared the bullfrog allowing the user to select one to view your analysis. The user clicks on salamander. You display the bullfrog-salamander comparison in the rightmost content frame where the bullfrog overview had earlier been displayed. But you still want that overview directly in view to the user, not just available.

So when you displayed the bullfrog-salamander comparison it automatically (we'll explain how in a minute) caused the bullfrog overview to now be displayed in between the left and right frames ^{of the three} in the middle, the secondary frame. So now you have from left to right: a list of critters which can be compared to the bullfrog, a bullfrog overview, and your bullfrog-salamander comparison.

Now let us go to the static single page request scenario.

Using the search engine, the user finds your bullfrog-salamander comparison page and clicks. Naturally upon arrival, you want him to see the list in the left, the bullfrog overview in the middle and the bullfrog-salamander comparison in the right.

Notice, upon arriving he doesn't have to search for bullfrog. He doesn't have to search for bullfrog-salamander comparison, or a salamander-bullfrog comparison. He doesn't even have to click on the list. He already knew what he wanted because he found the page by using the search engine. You already know what he needs, so you display it. It is a nearly seamless transition between the search engine and your site. No diversions or distractions and more importantly no frustrations.

Now let's go back to the dynamic situation.

A user can also click on the treefrog. The same sequence of events occurs. Now from left to right you have: a list of critters which can be compared to the bullfrog, a bullfrog overview, and your bullfrog-treefrog comparison.

Back to the static single page request scenario.

The same scenario takes place as with the bullfrog-salimander scenario but this time with regard to the bullfrog-treefrog. Naturally upon arrival, you want him to see the list in the left, the bullfrog overview in the middle and the bullfrog-treefrog comparison in the right.

Now let us analyse.

We see that there is a common page: the list. And a second common page: the bullfrog overview. And finally the specific page, either bullfrog-salamander comparison or bullfrog-treefrog comparison.

So we see in these circumstances that both the bullfrog-salamander and bullfrog-treefrog pages could reference a common bullfrog comparison frameset which looks just like the:

org_AEDOK__f_single-page-request_main-clf_ala_com.html
org_AEDOK__f_single-page-request_SE-clf_ala_com.html

framesets that you are using, BUT would be preset ^default to load the two common pages ^frames and, by proper specification, the specific page ^frame of the single page request.

But in the static situation what if the user had found your list of critters page or your bullfrog overview page instead of the bullfrog-salamander comparison ^page or the bullfrog-treefrog comparison ^page?

Upon his arrival, you would naturally want the bullfrog overview in the rightmost content frame. You would still want the list of critters in the leftmost frame. But the middle frame is vacant. Under this situation, you could do any number of things. You could display your credentials. Or you could explain that the user has jumped into the middle of an analysis and give instructions on how he should select a critter from the leftmost frames list.

To do every thing in this example so far, your need only the original four pages: the critter comparison list, the bullfrog overview, and the bullfrog-salamander and bullfrog-treefrog comparisons, plus a single additional frame set page as follows:

org_edu_mySubDomain__f_single-page-request_bullfrog-comparison.html

Don't be put off by the length of our names. You can use much shorter ones, but some of the specification is required. We shall discuss that later. This new framset, which we shall refer to here as bullfrog-comparison frameset:

specifies that it is to be loaded into frame f_main_work of org_AEDOK__f_single-page-request_main-clf_ala_com.html.

specifies that by default the list of critters ^{the leftmost frame} is to be loaded into f_SE_primary.

specifies that by default the bullfrog overview instructions is to be loaded into f_SE_secondary.

specifies that by default the bullfrog overview ^{the right most frame} is to be loaded into f_SE_content.

specifies that by default your testamonials or cridentials is to be loaded into f_main_adm ^{the top most frame}.

The bullfrog overview page

specifies that it is to be loaded into f_SE_content overriding the default, which you know is itself, but always specify where a page is to be loaded in an init() ^group script

The bullfrog-salimander comparison page

would specify that the list of critters is to be loaded into f_SE_primary overriding the default, but you know that is the default so you skip that, unless you have dozens of pages, you can get confused, and you want to be certain. It does not cause a problem if you specify what is already the default..

specifies that the bullfrog overview is to be loaded into f_SE_secondary overriding the default, the bullfrog overview instructions.

specifies that it is to be loaded into f_SE_content overriding the default.

The bullfrog-treefrog comparison page

would specify that the list of critters is to be loaded into f_SE_primary overriding the default, but you know that is the default so you skip that.

specifies that the bullfrog overview is to be loaded into f_SE_secondary overriding the default, the bullfrog overview instructions.

specifies that it is to be loaded into f_SE_content overriding the default.

The list of critters page

specifies that it is to be loaded into f_SE_primary overriding the default, which you know is itself, but always specify where a page is to be loaded in an init() ^group script

would specify that the bullfrog overview instructions is to be loaded into f_SE_secondary overriding the default, but you know that is the default so you skip that.

specifies that an introduction to your website is to be loaded into f_SE_content overriding the default.

The initFrame YYMMDD() script is used to accomplish the above (because the initLoad YYMMDD() script which was also indicated is necessary anyway. So there is only one additional script type.)

Of course there are numerous variations on this example. But one can see that by using just this one technique this one capability, it is possible to create very professional entries into your website. no stumbling around, double or triple searches or other diversions.

as a side note we would point out that many websites count on these diversions to interest you in what they really want to pedal. but it is distasteful unprofessional, and not forthright .

And it looks more complicated in writing than when one just visualizes it. Here is what you do:

Establish what you want it to look like in a default situation where you don't have enough pieces but you don't want to leave frames empty, waisting space and opportunity. That is your default specifications for the frameset, for the single page request.

For each page that can use this new frameset visualize the surroundings and what should look like. What does this page need for proper context and understanding?

Compare this visualization to the default situation. For the page itself one always specifies the frame it needs and the script always automatically overrides any default.

Then one simply adds appropriate initFrame YYMMDD() scripts to fill in the context. Bingo!

moving right along, ...

But, just like the Popeil Slicer and Dicer , there's still more.

Remember, the single page request handles the static situation. and we have just enhanced the statics situation by adding support frames to augment the context. But even though in the above discussion we jumpef back and forth between the static and the dynamic, the work we did and the frame specifications we added we're for the static situation in order to as closely approximated we can the dynamic situation.

In this static situation, the entire world is treated as one. Each and every single page request is essentially coming from the same location in the same context. That single location and context is: "outside the website."

But from within the website, we have a dynamic situation. To where a page is loaded and what support frams it requires depends upon circumstances such as which link from which other page is referencing said page. So in the dynamic situations, it might appear that the default pages specified in the initLoad YYMMDD() script and any additional intFrame YYMMDD() scripts all specified for the static situation anyway, should not be automatically loaded because they don't represent the dynamic context. One certainly can't load them all the time. That would often be clobbering numerous frames one had already established, in what might be a complex and lengthy drilling down as it's called.

However, there are dynamic situations which are identical to or closely resemble the static situation, the single page request. In these cases, it would be convenient to be able to load those support frames automatically, or at least some of them. In our bullfrog example above, if the user had saved any of those pages as bookmarks, more preferably using the AEDOK todoitQtm, then upon reference, that would be identical to a single page request. Or on the author's side of the picture, that would be you, you might have created another list, a list of important comparisons. That too would be identical to a single page request.

So it is desirable sometimes to be able to specify that the single page request frameset defaults pages be loaded. (Remember in the dynamic situation where the user is already at your website, the framesets themselves have already been loaded, so we are talking here about the context created by the default pages, not by the frameset which has already created its context and ambiance.)

This is accomplished by utilizing the todoitQ1() script. in conjunction with the intLoad YYMMDD() script already specified and any additional intFrame YYMMDD() scripts.

The todoitQ1() script is always placed at the point of reference to said page in lieu of a standard hyperlink reference anyway. All one need do is add a parameter which indicates that the sprPages (which would normally be ignored because this is not a single page request, it is a standard, dynamic, at-the-website, hyperlink reference) be loaded.

And there really is just one more important point.,

Suppose in our bullfrog analysis, when the bullfrog-salamander comparison page is loaded, that in addition to what we discussed, as it's support documents it specified a detailed summary which it loads into Ktm's window ^f_main_admusing an intFram YYMMDD() script.

Now, in your secondary list which contains the links which reference the bullfrog-salamander comparison page (which when clicked also loads all support documents including the one we have now added, the details summary), suppose that rather than one link there are two. Possibly a pair of small buttons. One indicates that you want the detailed summary, the other that you want the summary summary.

So we now I have two valid contexts in which the comparison pages can be loaded. One context is detailed and the other is brief. But neither the single page request context nor the context created by the intFram YYMMDD() script we've specified for the dynamic situation, is applicable.

The solution to this theoretical dilemma is the intPageGroup parameter in the intFramyymmdd() script. So in the above where we were specifying intFramyymmdd() scripts, for the bullfrog-salamander comparison page, we specify an additional intFramyymmdd() script for this new context and specify in the intPageGroup parm of the script: dcGroup, which stands for Dynamic Common Group.

And, since we have now found a second valid context, we cannot be certain that there would not be a third. And indeed one can easily conjure up additional contexts. Therefore this group specification allows, in the addition to predefined names, any additional alpha-numeric name that you require to assist you in your classification of the groups. They don't need to be defined enumerated or declared. The loading scripts simply compare what you've specified in the intFramyymmdd() script with what you have requested in the todoitQ1() script.

In summary, we've jumped around a little and we've left out all sorts of details. but this discussion was not intended to educate you precisely regarding the techniques, but rather to bring to light some of the interactions we perceive in a sophisticated contextual environment, and some easy ways to address these interactions. The specification for the individual parameters are indicated in the definitions of the scripts.And precise, simple, implementation is indicated in the step-by-step implementation section.

Caveat

Summary

Self locating is the ability of a loan page from a single page request to essentially load the entire website. This is relatively common for commercial websites. Contextually self locating is the ability of a single page request to load, in addition, support pages to establish a broader context specific to the single page request page. Without advanced dynamic page generation software it is difficult to accomplish. Web pages generated ^published by common website publishing software do not have this ability.

AEDOK accomplishes both self location and contextual self location utilizing proprietary techniques, which naturally, are available to all Level 4 Active Members.

Self location is accomplished thru the use of the init() script. The init() script achieves basic self location but not the more advanced contextual self location. The init() script is used for framesets themselves since they establish the context. Also becuase it has fewer parameters, it is also used for specialized situations like self learning.

Contextual self location is accomplished thru the use of the initLoadyymmdd() script. The initLoadyymmdd() script is used in lieu of the init() script. Required is either one or the other, never both.

Further, the concept of contextual self location, can be broken into three(3) broad groups with a fuzzy and overlapping borders towit:

single page request (context establishing pages) aka sprPages or sprGroup. These are pages which establish the general context of the individual page in the static situation of an external request for said page, in addition to the website's standard context and theme producing pages. For example, a help page is not going to have the same context, the same surrounding subpages and supporting documents, as an in-depth analysis of the bullfrog.

dynamicCommon (pages common to numerous dynamic circumstances), aka dcPages or dcGroup. These are pages which ^often one would want loaded anyway in the dynamic situation of a link from within one's own website to said page, such as testamonials and credentials.

dynamicSpecific (pages specific to the individual page regardless of dynamic circumstances), aka dsPages or dsGroup. These are pages which properly belong with said page in the dynamic situation of a link from within one's own website, such as lists, documentation, references, and citations.

The initFrameyymmdd() script is used to load these support frames.

But ironically,in the final analysis it turns out that the borders between these three groups is so indeterminent that one cannot specify with certainty into which group any particular support frame should be placed. The solution to this theoretical dilemma is as follows:

The initFrameyymmdd() scripts which individually specify a support page and destination frame among other things, and which are placed in the page requiring these support pages, has an initPageGroup parameter. The initPageGroup parameter specifies one or more groups in which the represented page belongs. The specification is in the form of alphanumeric names. There are three(3) predefined names: sprGroup ^{single page request}, dcGroup ^{dynamicCommon}, and dsGroup ^{dynamicSpecific}, plus any number of additional group names specified by the author to facilitate easy grouping. The loading sequence and priorities is as follows:

On a single page request, the sprGroup is loaded after the standard AEDOK frameset. Thus the contextual self location context has been established.

On a click or mouseover ^{author specifiable}, of a link specified by a todoitQ1() script ^{which replaces standard hyperlink references} in a page of the AEDOK Suitetm of Websites & Domains, the dcGroup is loaded, unless otherwise specified in said todoitQ1() script. The standard AEDOK frameset has already been loaded, as well as any other other specified pages and frames on the website containing the reference, and any (other than restricted) frames will be reloaded according to this dcGroup specification. Thus the dynamic common context has been established, such as testamonials and credentials.

On the same click or mouseover, of said link specified by said todoitQ1() script, the dsGroup is loaded, only if specified in said todoitQ1() script, as well as any other groups only if specified. Thus the dynamic specific context has been established, such as lists, documentation, references, and citations.

But, additionally, the order of the pages loaded within a given group is in accordance with the order of the physical placement of the initFrameyymmdd() scripts. All these factors combined provides a cascading style capability, rendering it unnecessary to worry about the single page request context or the dynamic common context interfering with the more important dynamic specific context.

So you control the sprGroup at the time you create the specific page, and you control the dcGroup and dsGroup at the point of reference to said page within your website at the context point.

DEFINITION SUMMARY

Thus ends the initial installment of definitions.

Note hat we left out countless details and specifications because this section is not intended for that purpose. But we tried to give sufficient details and specifications to render the discussion intelligible.

We will now proceed to the scripts but will introduce additional definitions as needed.

FOOTNOTES

Integrating Web Pages Smoothly Into The AEDOK Suitetm of Websites & Domains Required & Optional Scripts

scripts OVERVIEW

The scripts are of two(2) varieties: required and optional. The required scripts are required in order for the page to integrate smoothly into the AEDOK Suitetm of Websites & Domains. The optional scripts provide either convenience to, or functionality for, the author, the AEDOK Level 4 Active Member.

Naturally, all specifications must be letter perfect, but in addition to this requirement, we must point out that because we have achieved the difficult feat of cross domain referencing using relative addresses (not absolute addresses), the concept of relative addressing must be understood in a more complex context. Traditionally, the relative address specified is relative to the page containing the reference. This is clear and simple. However, AEDOK references do not always result in a link at the point of reference, but rather, may be a specification for a link at a later time which could be, and most likely is, from a different page, and therefore possibly at a different level. Under these circumstances, one must have clear perception of what the relative address specification is relative to. Accordingly, we have already introduced a number of definitions to clarify these relative address distinctions.

Unfortunately, in the event of a page not found, many browsers do not have the courtesy of informing one of the name of the page or the address which had been specified. Remember, this is a multiframe environment, and the page name/address you reference will most likely not appear in the browsers url line. Under such circumstances, one does not know whether his error is a spelling error, a punctuation error, or a specification error, and may spend literally hours tracking down a single link!

However, utilizing AEDOK's todoitQtm one should be able to solve the problem quickly. At the farmost left of your screen under the AEDOK logo is the info frame ^f_main_info. It consists of numerous sub-parts. Once fully implemented, it will be possible to move these parts around. By default, located at the bottom is the todoitQtm framecheck. The todoitQtm framecheck keeps track of what is loading and what has loaded into a frame. You most likely know the frame name, so scan the list for the frame. It should indicate the url that was requested to be loaded into that frame. However, in the event you do not know the frame name, simply scan the list until you find a frame that has been marked not loaded. It is highly unlikely there would be more than one, so that should show the offending url. Also, there is an option in the controls to display the full url or just the tail.

At the time of this writing there are only three(3) required scripts, the Ktm init() ^{ie., one from the init group}and the todoitQ1tm and the todoitQ2tm. Because we have limited the number of required scripts, very little burden is placed upon the author to achieve smooth integration of otherwise functional pages into the AEDOK Suitetm of Websites & Domains. AEDOK can improve and enhance these required scripts with no effort required by the Level 4 Active Member. Naturally, with the passage of time additional functionality shall be continually added. But, the essential functionality of contextually self locating pages ^{which is more than run-of-the-mill self locating}, and the user controllable todoitQtm, are fully implementable with no more than the given three(3) required scripts.

Scripts Required: init()

Script init()

The Ktm init() script is the fundamental script from the init group. It initializes variables, settings, and features including basic self loading, but not contextual self loading. It is required in all pages (but not explicitly specified), for, it is called by one of the other scripts from the init group which the Level 4 Active Member does specify, the higher level Ktm inityymmdd scripts discussed next.

However, even though Ktm init() is not explicitly required, (providing one of the other scripts from the init group is explicitly specified), it can be specified in lieu of one of the other scripts from that group, under limited circumstances as follows:

There can be testing situations in which one is himself learning of the functionality of some HTML ^{javaScript, PHP, ect.} component. Under such circumstances, the specifications required by the more advanced scripts from the init group are often inappropriate, because those scripts are designed to be rudimentally self checking of the input parameters. These requirements can become a burden. Under these circumstances, Ktm init(), having only three(3) required parameters plus four(4) optional parameters, two(2) of which are debug parameters, can be quite useful.

Scripts Required: init()

Script init()

init(), aka init() script

Definition

init() script initializes variables, settings, and features including basic self loading, but not contextual self loading.

Syntax

init( clfUrl, clfToFrame , clfOfFrameset , initTopSub , initType , debug , iam );

Abbreviations

clf
clear and load frames

init
initialization

Functionality

The init() script returns no value, but sets numerous global variables. It is required in all pages (but generally not explicitly specified), for, it is called by one of the other scripts from the init group which the Level 4 Active Member does specify, the higher level Ktm initYYMMDD scripts.

Parms

Parm 1: clfUrl

The technical full name ^{not the display name/title}of the page containing the script. A string value in the form of a frameset relative address ^{defined earlier}. if you understand the information presented regarding a frameset relative address and a backaround relative address then the following will be a refresher.

clfUrl consisting of three parts towit:

frameset relative address no-delimiter technicalPageName . extension

Subpart: frameset relative address

The frameset relative address of the page with respect to clfOfFrameset ^{parm 3}.

Subpart: technicalPageName

The case sensitive, alphanumeric, dash and underscore name of the page

Subpart:extension

The type of page in preferably lower case (html, php, etc.). AEDOK conventions are lower case, upper case will work if your publishing software insists. upper case will simply make your page nameing syntax slightly inconsistent and confusing.

Parm 2: clfToFrame

The name of the frame into which clfUrl ^{parm 1} is to be loaded.

Parm 3: clfOfFrameset

The name of the frameset page containing the frame clfToFrame ^{parm 2}

Parm 4: initTopSub

The full sub domain name at AEDOK consisting of multiple parts singleUnderscore(_) delimited towit:
top _ sub _ subSub _ subSubSub .. The singleUnderscore(_) is a delimiter, not a specifier. accordingly, there is no leading singleUnderscore(_) and there is no trailing singleUnderscore(_).

Parm 5: initType

An integer value of [ -2, -1, 0, 1, 2 ] to indicate the type of page technically in the event of a single page request.

Parm 6: debug

An integer value of [ 0, 1, 2 ] to specify the level of debug tracing.

Parm 7: iam

A string used with debug ^{parm 6} to provide additional tracing information.

Usages

Usage: Initializing frameset pages.

framesets do not require contextual self loading which init does not provide because framesets provide the context. Subsequently, other pages requiring a context, and therefore contextual self loading, utilize the context provided by said frameset.

Example

Initializing AEDOK's standard single page request frameset with all default pages.

init("org_AEDOK__f_main-clf.html","","org_AEDOK__f_main-clf.html","",1,0,"html");

In the above example, any existing frames in the current browser window will be cleared and the frames themselves will be eliminated, then the clfOfFrameset ^{Parm 3} by name org_AEDOK__f_main-clf.html, will load into the browser window with all default frames ^pages.

The reason all defaults are loaded is because clfToFrame ^{Parm 2} is null. Had clfToFrame ^Parmbeen specified, init()would initiate an alert followed by an abort. The reason is because clfUrl ^{Parm 1} is equal to clfOfFrameset ^{Parm 3}. clfUr ^{Parm 1} is the name of the page and clfOfFrameset ^{Parm 3} in the frameset to be used, and they can properly be the same, but one cannot load the page into itself.

Further, in this example, initTopSub ^{Parm 4} is null. This is permitted, because the information it would have provided is presented in the first segment of clfOfFrameset ^{Parm 3}, as indicated by the double underscore(__) in clfOfFrameset ^{Parm 3}. AEDOK recommends this page naming convention because it clearly associates the page with its source. Though it is true that is not sufficient information to load the page, because the directory specifications are not given in this technique, it is sufficient information to eliminate any ambiguity as to who's page it is.

Remember, the AEDOK Suitetm of Websites & Domains is designed to permit cross subdomain relative addressing. AEDOK encourages members to reference one another's pages, techniques, and insights. But, though AEDOK recommends this page naming technique, it does not require it, for such a requirement may impede one's style. And, the requirement is not technically necessary since the information is available from initTopSub ^{Parm 4} which is what that parm was designed for.

Moving right along, further, in this example, initType ^{Parm 5} is 1 which specifies that this is a frameset. Note again, we could have derived this frameset information from the first part of the second part of clfOfFrameset^{Parm 3}, to wit: f_, another AEDOK page naming convention, thereby not requiring initType ^{Parm 5}. However, gleaning critical information from the name of a file as one goes deeper and deeper into the name, requires a more precise syntax and once again impediments to style. Such being undesirable, that is what that parm was designed for.

Finally, in this example, we come to the optional parameters, debug ^{Parm 6} and iamCaller ^{Parm 7}. Notice that although the perameter debug ^{Parm 6} itself is a numeric value, one can in all such parameters, numeric or otherwise, specify a variable, which we have done here by using a variable of the same name, for both. The variables do not have to be the same name, we just find it easier to keep track of things that way. The script variable debug ^{defined earlier} is our commonly used variable which we often switch from 0 to 1, though it has other values, thereby allowing activation of an entire sequence of debugging alert traces. The script variable iamCaller ^{defined earlier} is the variable which we generally set to the name of the page or script containing the init() call, with any prior callers appended to its name. We almost always use the pair together, and all scripts allow specification of these 2 optional parameters debug and iamCaller even scripts having no required parameters, because it is useful to have, the name and prior callers. However, the perameter itself iamCaller ^{Parm 7}, is actually a string value and one may insert any useful textual information such as line numbers ^{in quotes}, program locations, or error messages.

Usage: Learning about web functionality.

There can be testing situations in which one is himself learning of the functionality of some HTML ^{javaScript, PHP, ect.} component. Under such circumstances, the specifications required by the more advanced scripts from the init group are often inappropriate, because those scripts are designed to be rudimentally self checking of the input parameters. These requirements can become a burden. Under these circumstances, Ktm init(), having only three(3) required parameters plus four(4) optional parameters, two(2) of which are debug parameters, can be quite useful.

Example

[html>
[html>

Analysis: init(), aka init() script

clfUrl stands for "clear and load frames, url". The term "clear and load frames" is an AEDOK term representing the action required to fulfill a single page request. The term "url" is the url to be loaded.

For a fairly quick comprehensive understanding of this functionality of this script, proceed from left to right and visualize the simple variations first, viz:

clfUrl ^{Parm 1} is loaded into clfToFrame ^{Parm 2} of frameset clfOfFrameset ^{Parm 3}. If clfUrl ^{Parm 1} is clfOfFrameset ^{Parm 3} and clfToFrame ^{Parm 2} is null, then all default pages will be loaded. These default pages are specified in the body of the actual frameset page, which we call here clfOfFrameset ^{Parm 3}.

Notice we say, "If clfUrl is clfOfFrameset and clfToFrame is null, ...". Indeed, if clfUrl ^{Parm 1} is clfOfFrameset ^{Parm 3} then clfToFrame ^{Parm 2} must be null because one can not load a frameset into itself!

The script checks for this condition and issues an abort error if clfUrl ^{Parm 1} is clfOfFrameset ^{Parm 3} and clfToFrame ^{Parm 2} is not null.

We could have simply "corrected" the error by ignoring clfToFrame ^{Parm 2} (ostensibly in the name of robustness), but that would give the impression that such specifications are correct, which they aren't, and later on down the line one could easily become confused as to why other things don't behave in accordance with the implications of the wrong usage.

Caveat

Summary

Parameter Details

Reminder

Now in this discussion of init() we have, and we have before, and we shall continue to, present considerable detail regarding debugging capabilities. You may be wondering why we are discussing debugging programs when you, are supposed to be publishing your intellectual work product!

Remember, these scripts which are actually quite easy to use, have been designed in an environment consisting of multiple subdomains, utilizing browsers that arrogantly refused to give the name of the page that they could not find, evidently a systemic inability to give the name of the page requesting the page that could not be found, and ridiculous JavaScript which usually gives no indication of an error but rather proceeds and pretends as though there was none, ostensibly in the name of robustness, which results in unpredictable, non- understandable, chaotic results !

You should not, and most likely will not, have these problems. If you install a page which comes up not found, check the parameters, punctuation, and spelling, and the problem should be quickly rectifed

Finally, this debugging is not an ongoing thing. Once a page is installed and operational, you are done. Until of course you make another reference to it which of course must be properly specified.

By the way, the reason our narration is oftimes detailed and lengthy, is because it is in our nature. We are, after all, AEDOK, the Archive for Education and Dissemination Of Knowledge.

And Thank You for being a part of it.

Scripts Required: init()

init ( clfUrl , clfToFrame , clfOfFrameset , initTopSub , initType , debug , iam ); optional

Parm 1: clfUrl

Purpose

Address of page to initialize and load.

Status

Required

Type

String

Format

Fixed

frameset relative address

Form

framesetRelativeAddressPt technicalPageNamePt

Descript

The frameset relative address of the page clfUrl with respect to clfOfFrameset ^{parm 3}.

Leadin

Parts

Separate

Leadout

Eg 1 real

../all/ all_all__about_mission__intro .html

Pt 1

framesetRelativeAddressPt

Form

framesetRelativeAddress of page clfUrl with respect to frameset clfOfFrameset.

Descript

Starting at the address of clfOfFrameset ^{parm 3}, backup( ../ ) as many levels as necessary to get to level 3 which is depth 1, eg., all, edu or ent. Then backup( ../ ) one more level. Finally, go forward( subDomain/ ) thru any necessary subDomains, starting with eg., all/, edu/ or ent/, and go forward( dir/ ) thru any necessary directories all the way down to the page clfUrl, but don't include the page which is described separately next.

Leadin

SubPts

Buried in Description.

Separate

Buried in Description.

Leadout

Buried in Description.

Eg1p1 real

../all/

Pt 2

technicalPageNamePt

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), and underscore( _ ) name of page, including dot( . ) extension.

Leadin

SubPts

See Form.

Separate

dot( . )

See Form.

Leadout

Eg1p2 real

all_all__about_mission__intro .html

Eg 2 real

all_all__about_mission__intro .html

Pt 1

framesetRelativeAddressPt

Eg2p1 real

null

Pt 2

technicalPageNamePt

Eg2p2 real

all_all__about_mission__intro .html

Parm 2: clfToFrame

Purpose

Frame of clfOfFrameset into which clfUrl is to be loaded.

Status

Illusive

Detail

If clfType ^{parm 5} is 1, that means that clfUrl ^{parm 1} is a frameset itself. In that case there are two possibilities towit:

First of two(2) possibilities: If clfUrl ^{parm 1} is the same as clfToFrameset ^{parm 3}, that means we are clearing and loading framess from scratch, and frameset clfUrl ^{parm 1} is the first to be loaded. In this case, clfToFrame ^{parm 2} must be specified null, otherwise we would be loading this page into a frame of itself.

Second of two(2) possibilities: If clfUrl ^{parm 1} is not the same as clfToFrameset ^{parm 3}, that means we are loading frameset clfUrl ^{parm 1} into another frameset, namely clfToFrameset ^{parm 3}, so clfToFrame ^{parm 2} must not be specified null, it must be specified, otherwise we would not know into which frame it should be loaded.

See clfType ^{parm 5} below for complete enumeration of possibilities.

Type

String

Format

Fixed

f_ frameName | f_ frameName _ subName | etc.

Form

frameIndicator frameName [ subName [ ... ] ]

Descript

AEDOK frame naming conventions consist of a frameIndicator character( f ) followed by a sequence of alphanumeric names, each component including the frameIndicator, being separated from one another by a single underscore( _ ), eg., f_main_work.

Both the frameIndicator and the separator are acceptable characters in the underlying HTML frame naming character set, and are therefore strictly speaking not punctuation. AEDOK simply uses this convention to establish a level of order in the frame naming conventions.

AEDOK recommends these conventions, you decide.

The reason is that in viewing a script reference, frame names established in this manner are easy to spot and thereby assist one in delineating in one's mind what are sometimes numerous parameters.

Leadin

Parts

At least 2

Separate

underscore( _ )

Leadout

Eg 1 real

f _ main _ work

Pt 1

frameIndicator

Form

The lower case character( f )

Leadin

SubPts

Leadout

Thus

Pt 2

frameName or frameGroup

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), and no underscore( _ )

Leadin

SubPts

Leadout

Eg1p1 real

main

Pt 3 etc.

subName in frameGroup

Form

Repeat part 2 immediately above.

Eg1p2 real

work

Eg 2

f _ main

Pt 1

frameIndicator

Eg2p1

Pt 2

frameName or frameGroup.

Eg2p2

main

Pt 3 etc.

subName in frameGroup

Eg2p3

n/a

Parm 3: clfOfFrameset

Purpose

Frameset containing clfToFrame into which clfUrl is to be loaded.

Status

Required

Type

String

Format 1

NOT IMP

~~domain-relative address~~

Status

domainRelativeAddress NOT IMPLEMENTED

Form

domainRelativeAddress

Descript

Leadin

Parts

Leadout

Eg 1

org/edu/knowItAll/frameset_main.html

Format 2

Prefered

domain-relative address as part of page name

Form

topSubPt descriptivePt [ framesetExtensionPt ] htmlPt

Descript

The naming of a page incorporating the full domain-relative address in a manner compliant with conventional page naming syntax and characters, but with additional syntax such that:

The address portion of said domain-relative address is specified here (1st) as topSubPt, replacing any slash( / ) with under( _ ), to indicate the subParts,

What wuld have been the page name being specified (2nd) as descriptivePt, separated from the first by a doubleunder( __ ),

An optional extension to the frameset being specified (3rd) as framesetExtensionPt, separated from the second by a trippleunder( ___ ), if present otherwise no trippleunder( ___ ) either.

And the original html extension being specified (4th) as htmlPt, separated from the second (or third) by a dot( . ), this last part being of course any other valid extensions in addition to html, even though we refer to it here as html, but nothing past it.

This entire sequence is what one names the page on his computer in his web publishing package.

Leadin

Parts

Separate

Pt 1 Subs

under(_)

Re:Description.

Separate

Pt 2

2under(__)

Re:Description.

Separate

Pt 3

3under(___)

Re:Description.

Separate

Pt 4

dot(.)

Re:Description.

Leadout

Discuss

init() script requires the domain-relative address. The sequencing and priorities are as follows:

init() script looks to initTopSub ^{parm 4} for the domain-relative address.

If not spec, init() script looks to topSubPt ^{parm 3} (Format 2) for the domain-relative address.

If not spec, the page won't do a proper load on a single page request, but all else being proper, will still load on a standard reference from your website whether using todoitQtm scripts or not. Further, when you initially test the page by generating a manual single page request, init() script will issue an alert if possible, thus allowing you to correct the problem.

Independently, if topSubLeadoutPt ^{parm 3} (Format 3) is spec, init() script prepends initTopSub ^{parm 4} to the frameset name before looking for said frameset coincidentally utilizing initTopSub ^{parm 4} as it's address.

If not spec, again the page won't do a proper load on a single page request, but all else being proper, will still load on a standard reference from your website whether using todoitQtm scripts or not. And further, when you initially test the page by generating a manual single page request, init() script will issue an alert if possible, thus allowing you to correct the problem.

Finally, if both topSubPt ^{parm 3} (Format 2) and initTopSub ^{parm 4} are spec, init() script will use topSubPt ^{parm 3} in determining both the name and address of the associated frameset, but use initTopSub ^{parm 4} for all else.

To reitterate this last step, init() script will not replace topSubPt ^{parm 3} (Format 2) with initTopSub ^{parm 4} in a manor similar to Format 3 whereby it prepends initTopSub ^{parm 4} to the name, which would override topSubPt ^{parm 3}, but will rather, use topSubPt ^{parm 3}.

Eg 1 real

org _ AEDOK __ f_single_page_request_main-clf_ala_com . html

Eg 2

initLoad150801(
"localPage.html" ,
"f_SE_content" ,
"org_edu__f_spr_main___group2.html" ,
"org_edu_knowItAll",
0 ,
debug , iam
);

Eg 2 det

org _ edu __ f_spr_main ___ group2 . html

Eg 2 desc

localPage.html, will be loaded into frame
f_SE_content, of frameset
org_edu_knowItAll__f_spr_work___group2.html, located in
org/edu/knowItAll, after said work frameset is loaded by
org_edu__f_spr_main.html, located in directory
org/edu, an AEDOK directory.

Note that the value of 0 for initType ^{parm 5} indicates that
localPage.html, is a standard page.

Eg 2 ana

localPage.html, is a local page because it has no address spec and is therefore local to the root directory of this specific subdomain org_edu_knowItAll, thus org/edu/knowItAll.

It will be loaded into frame f_SE_content which needs no address because it is a frame.

f_SE_content is a frame in either org_edu__f_spr_main.html or org_edu_knowItAll__f_spr_work___group2.html, it doesn't matter as the frames of a nested frameset are collected together with the frameset that loads it. (So, we don't ackually know from these spec that it is a frame of org_edu_knowItAll__f_spr_work___group2.html, but again all that matters is that it is a frame of the total frameset being loaded.)

The initial frameset org_edu__f_spr_main.html is located in org_edu spec in it's name.

It will first load the frameset of similar name plus framesetExtensionPt ___group2, the resultant name being org_edu_knowItAll__f_spr_work___group2.html which itself is located in org_edu_knowItAll, spec by initTopSub ^{parm 4},thus org/edu/knowItAll.

The value of 0 for initType ^{parm 5} indicates that localPage.html is a standard page and refers to the page being loaded, not the framesets required to load it.

topSubPt

Form

See initTopSub ^{parm 4}

Leadin

SubPts

Multi

Separate

under( _)

See Format 2 Description.

Leadout

doubleUnder( __ )

Descript

topSubPt and initTopSub are identical except that topSubPt is a part of this format and precedes descriptivePt and is actually a part of the page name (if one elects to use this format) but initTopSub stands alone as simply a parm.

Discuss

AEDOK uses this format exclusively because it allows one to see both the path and the page at the same time without having to backtrack through the directory structure. It has the disadvantage that if you move the page then the path is no longer valid, and so one would have to change the page name in addition to moving it, and additionally that requires opening the page to change the page name internally. But, one would have to change initTopSub and that requires opening the page. And one would have to change all references to the page name in any event. And in the final analysis, the number of times a person looks at the page name is orders of magnitude greater than the number of times he moves it.

One additional advantage to this technique is that regardless of how hard one tries, a directory inevitably collects files that are not pages uploaded to the website. These are generally intermingled with the website pages in a manner similar to shuffling a deck of cards. But by using this technique on naming functional web pages, they become automatically grouped together leaving the flotsam to float elsewhere.

Of course, under different circumstances it would be ridiculous to follow this technique, for it defeats a couple of advantages of a subdirectory structure. But it serves its purpose here.

AEDOK recommends this technique, you decide.

Eg1p1 real

org _ AEDOK __

Eg2pt1

org _ edu __

Pt 2

descriptivePt

Form

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

Leadin

SubPts

Leadout

Descript

The normal page name one would have given the page using html syntax and character set.

Discuss

Because browsers have idiosyncracies, it is wise to use a conservative character set comprises as above, though AEDOK uses also the leftParen( ( ) and rightParen( ) ). Remember, your file name must not just pass your computer's file system's requirements for page naming, it must also comply with AEDOK web hosting system's requirements as well as your browser and hopefully everyone's browser throughout the world.

html may strangle on less conventional characters. Specifically, the page name must be capable of being used in the html local page reference naming technique

... href="pageName.html#localRef" ...
.
.
.
< a name="localRef">

where you have provided the pageName and either you or we provide the localRef, as well as other techniques. Even the dash( - ) poses some problems when using javascript, but none we have not so far been able to circumvent.

AEDOK recommends this technique, you decide.

Discuss

Further, there are two opposing techniques utilizing a combination of the dash( - ) and the under( _ ). The first is to use the dash( - ) to separate and the under( _ ) to create word phrases without using space. The second is the reverse. We have determined that due to the size of the ( _ ) being larger than the dash( - ) and thus more suitable for separation, that this second technique is better. That is, to hyphenate phrases into single-word-concepts, as we have just done, and use the under( _ ) to separate without using spaces.

Eg., notice in our frame name

org_AEDOK__f_single-page-request_main-clf_ala_com.html

the part single-page-request is "one-word-phrase", so to speak, separated from main-clf (which means main-clear-and-load-frames) another word-phrase, by the under( _ ), which is then separated from ala which means "in the manor of", further separated from com, (used in our com domain). These so-called separations are sort of like very loose conceptual subdivisions, whereas the word-phrases are multiple words use to covey a single thought.

AEDOK recommends this technique, you decide.

Important

AEDOK use doubleUnder( __ ) for special syntactical separation as well as tripleUnder( ___ ) for another syntactical separation in the framesetExtensionPt as described above.

You must not use doubleUnder( __ ) or tripleUnder( ___ ) or any other multipleUnder( ____ ) for any purpose other than as we have spec in this documentation, otherwise all manor of calamity will ensue.

Eg1p2 real

f_single_page_request_main-clf_ala_com

Eg2p2

f_spr_main

Pt 3

framesetExtensionPt

Form

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

Leadin

tripleUnder( ___ )

SubPts

Leadout

Descript

A frameset subdivision name which has no meaning in html but which has meaning to Dimensions tm whereby an AEDOK frameset by name
topSubPt descriptivePt . htmlPt
which would normally load a nested frame of a name similar to it's own, but in your directory specified by initTopSub ^{parm 4} , will now instead reference a frameset of similar name with framesetExtensionPt inserted between the end of said similar name and the htmlPt, thus:

topSubPt similarPt ___ framesetExtensionPt . htmlPt

Discuss

As discussed before, a frameset can load into one of its frames a page which itself is another frameset, called a nested frameset. Normally, for convenience and to avoid unnecessary confusion, both pages are in the same directory, and very often of similar name. AEDOK provides a number of such framesets as part of the AEDOK Dimensions tm v 1.0 Web Publishing Platform.

These preestablished framesets referenced, which we generally referred to as main and as often contain the word main, establish the overall AEDOK theme, the logo, copyright etc. Then, the main frameset loads the other frameset, the nested frameset, which we generally refer to as the work frameset and again generally, but not always, having the word work in it's name, into the main work area thus establishing the basic structure for the work area. The AEDOK Level 4 Active Member can utilize some of the frames in the main frameset and most if not all of the frames in the work frameset. Said framesets are pre-assembled and the fact that they are in an AEDOK directory is of no consequence since all you need to know is the their names, location and the frame names into which you are going to load your pages.

However, for additional flexibility, the AEDOK Level 4 Active Member can design and specify his own work framesets. Naturally, in order to maintain an over all uniform user experience at the AEDOK Suitetm of Websites & Domains the Dimensions tm v 1.0 Web Publishing Platform maintains control over the main frameset and then loads the Level 4 Active Member's work frameset situated in one of his directories, or indeed, another Level 4 Active Member's frameset, should it be creative and serve better a specific purpose or mode of presentation. In this way, Level 4 Active Members enhance each other's capabilities.

The Level 4 Active Member's work frameset has a name identical to the AEDOK frameset he has selected with one difference being that the word main is replaced by the word work. The init() script initTopSub ^{parm 4} parm allows specification of where this work frame is located.

Because these specs are on a page by page basis, contained within the top of each web page, said spec could be for any directory accessible to the Level 4 Active Member, not just his root directory, which is what initTopSub ^{parm 4} generally refers to.

However, for orderliness, AEDOK recommends one place his framesets in his root directory, but of course in a complex environment, in a suitable high level directory serving the lower levels.

AEDOK recommends this technique, you decide.

However, to further expand the freedom of variation, one may specify any number of work framesets of the similar name to the main one selected.

This is the purpose of framesetExtensionPt which is simply appended to the descriptivePt after changing the word main to work, thus:.
org_edu__f_spr_main.html
org_edu__f_spr_work___framesetExtensionPt.html

This naming convention applies only to these paired or grouped framesets that we create and describe in this manor. The other pre-established framesets referred to above which reside totally with in the AEDOK directories do not necessarily follow this naming convention, but need not for all one needs (as mentioned above) for their utilization is their name, location and the frame names.

Some Level 4 Active Member may spend their entire career utilizing only AEDOK provided standard frameset for we intend to make each one of them as functional and flexible as possible.

But we do attempt to refrain from arrogance and realize that there are any number of other configurations more suited to difference venues.

Eg1p3 real

Not used in this example.

Eg2p3

___ group2

Pt 4

htmlPt

Form

extension

Leadin

dot( . )

SubPts

Leadout

Descript

The standard extension on a page name, which for our purposes usually html or php, etc.

Discuss

Although we refer to is as htmlPt it includes any other valid extension

Eg1p4 real

. html

Eg2p4

. html

Eg 3 real

org _ AEDOK __ f_single_page_request_SE-clf_ala_com . html

Pt 1

topSubPt

Eg3p1 real

org _ AEDOK __

Pt 2

descriptivepart

Eg3p2 real

f_single_page_request_main-clf_ala_com

Pt 3

framesetExtensionPt

Eg3p3 real

Not used in this example.

Pt 4

htmlPt

Eg3p4 real

. html

Eg 3

org _ edu _ knowItAll __ frameset_main . html

Pt 1

topSubPt

Eg4p1

org _ edu _ knowItAll __

Pt 2

descriptivepart

Eg4p2

frameset_main

Pt 3

framesetExtensionPt

Eg4p3

Not used in this example.

Pt 4

htmlPt

Eg4p4

. html

Format 3

2nd Pref

domain-relative address from initTopSub ^{parm 4}

Form

[ topSubLeadoutPt ] descriptivePt [ framesetExtensionPt ] htmlPt

Descript

The naming of a page utilizing (but not incorporating) the full domain-relative address in a manner compliant with conventional page naming syntax and characters, but with additional syntax such that:

The address portion of said domain-relative address is not specified here, but rather, obtained from initTopSub ^{parm 4}.

However, the lead out portion of topSubPt, as defined in Format 2 above, the doubleunder( __ ), is optionally specified here as topSubLeadoutPt, to indicate that topSubPt is actually specified in the page name, but is omited here for brevity.

The descriptivePt is the same as in Format 2 above.

The optional framesetExtensionPt is the same as in Format 2 above.

And the htmlPt is the same as in Format 2 above.

Requires

You must spec initTopSub ^{parm 4}.

Discuss

init script requires the domain-relative address. In this Format 3 of specifying clfOfFrameset, the domain-relative address is obtained from parm 4 of the script, initTopSub.

The advantage of this Format 3 over Format 2 is most apparent when using initLoadyymmdd, which is the script normally utilized, whereby, the parameters though the first four(4) are the same are reversed the first parameter being initTopSub is followed by initFrameset which contains initTopSub (which is called topSubPt) as its first part when using Format 2 thereby producing visual clutter, especially if initTopSub becomes long as it can.

Eg:
initLoad150801( "org_AEDOK", "org_AEDOK__f_single-page-request_main-clf_ala_com.html" , "f_SE_content" ... vs.

initLoad150801( "org_AEDOK", "__f_single-page-request_main-clf_ala_com.html" , "f_SE_content" ...

Note

Be sure to read Format 2, Discuss to understand the interrelationships and priorities of initTopSub, topSubPt, and topSubLeadoutPt

Parm 4: initTopSub

Purpose

Specification of the absolute location (exclusive of page name) of clfOfFrameset within the AEDOK Suitetm of Websites & Domains.

Status

Contigent

If topSubPt is spec in clfOfFrameset ^{parm 3}, part 1 above, this parm 4 is not required, Otherwise , this parm is required..

Type

String

Format

Fixed

domain-relative address, exclusive of page name

Form

subDomain subSubDomain .. subDir subSubDir, ..

Descript

Complete sequence of subDomains followed by complete sequence of subDirectories up to but not including page, each separated from one another by a single underscore( _ ), collectively representing the domain-relative address exclusive of page.

Note

Be sure to read Format 2, Discuss to understand the interrelationships and priorities of initTopSub, topSubPt, and topSubLeadoutPt

Leadin

Parts

1 or More

Separate

under(_)

See Description.

Leadout

Eg1

org / edu / knowItAll / dir1 / deeper-dir /

Pt Each

subDomain subSubDomain .. subDir subSubDir, ..

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), and no underscore( _ )

Leadin

Leadout

SubPts

Eg 1

org_edu_knowItAll_dir1_deeper-dir

Eg 2

EG2FULL

Pt 1

REPEAT PT1NAME

Eg 2

EG2PT1

Parm 5: initType

Purpose

Indicates the type of page technically in the event of a single page request.

Status

Optional

Type

Integer

Format

Specific

Values

Page Type

Action

-2

Reserved

-1

Sys Funcs

No Action

Default

Regular

Clear And Load Frames (clf).

Frameset

Clear And Load Frames (clf).

Special

Load without clearing.

Values

End

Discuss

Used only for single page request. Specific values indicate the type of page from a technical point of view, not a content point of view. There are basically only three(3) types, towit: A common page, a frameset, and special system-functionality pages that for the most part one will likely never see.

Simply ask the question, "Is it a frameset or not?" Notice that the default is zero, since most pages are not, and the parm itself is optional.

For content type specification, use inityymmdd script defined below.

Parm 6: debug

Purpose

For debugging the initial integration of a page into the AEDOK Suitetm of Websites & Domains.

Status

Optional

Type

Integer

Format

Specific

Values

Depth

Action

Default

Off

Off, but critical alerts shall be issued.

Detail

On. alerts at significant points as a trace.

Important

On. alerts of important or summary info.

Values

End

Discuss

Debug allows one to see what AEDOK Dimensions tm thinks you want it to do, and what it is doing to accomplish that task. For the most part one needs it only if he just can't figure out why a page either won't load or loads into the wrong spot. It provides information as it figures out the page, name, location, destination frame and required frameset, et al.

Critical alerts are issued regardless. For example, by default, if a frame name can't be found, it alerts and attempts an abort. This is because something like not finding a frame name is generally not a dynamic situation, it is static. If a frame can't be found, it is most likely misspelled or belongs to a different frameset, either case of which occurs as one is integrating the page, and one needs to know immediately and with certainty.

But, to reitterate, once a page has been integrated, the frame name required will not change, and so the alert will never occur when a user is referencing that page.

But still, there are conceivable instances when it would be more convenient to turn off this specific check, or at least the alert and abort. For example, many browsers simply open a new window for frame not found, And, if one has not yet gotten around to defining a special frameset, but knows the name of the frame within it, he might want to spec the correct frame, and have the browser open a new window until such time as he solidifies the new frameset. So, eventually, there shall be the ability to change this default setting via user preferences, settings and controls.

Note

There are a plethora of other courtesy checks which inityymmddLoad script and inityymmddFrame script (not this init script) performs which are not critical but which none the less indicate that things will not go as intended. Again usually spelling errors which, eg., might result in the theme of a page being wrong. Currently those checks and actions are set to what we think are reasonable but eventually one shall have the option to set each and every one of them in accordance with dynamic requirements.

Parm 7: iam

Purpose

For debugging the initial integration of a page into the AEDOK Suitetm of Websites & Domains.

Status

Optional

Type

String

Format

Free

Discuss

When an alert is issued as per debug ^{parm 6} the intent is to provide tracing information within each alert so that one can follow the flow, in an environment which is otherwise implementor-hostel, as follows:

When a function is entered, a local variable iam is assigned is's name. When said function calls another function, it passes this name to that function, but adds information. When it was called, it's caller passed it's name which this function receives as the variable caller. So upon entry to a function, that function has it's own name and it's caller's name, so it sets a third local variable, iamCalleraller to the value of it's own name followed by it's caller's name, separated by a percent( % ).

This process goes on and on, so that every time a function is entered, one not only knows it's name, but who called it. Each time the list gets longer.

In a multi frame environment, and therefore multiple threads, each calling similar and/or the same functions often multiple times, otherwise one's mind is turned to putty.

For the initial call, for example in init, one can place any useful text string. AEDOK generally uses the variable iam, again, which we set locally to clfUrl just before the reference to init script. In this way, the sequence is complete and guaranteed.

AEDOK recommends this technique, you decide.

End

FOOTNOTE

Scripts Required: initLoad150801()

function initLoad150801( initTopSub, initFrameset, initFrame, initIam, initSpr, initType, initPageGroup, initPageTitle, initPageFunc, initPageLevel, initPageIcon, initPageIconAlt, debug, iam )

initLoad150801() ( initTopSub , initFrameset , initFrame , initIam , initSpr , initType , todoitQpageGroup , todoitQpageTitle , todoitQpageFunc , todoitQpageLevel , todoitQpageIcon , todoitQpageIconAlt , debug , iam );

Parm 1: initTopSub

Purpose

Specification of the absolute location (exclusive of page name) of initFrameset within the AEDOK Suitetm of Websites & Domains.

Status

Required

Type

String

Details

See init() ^script parm 4 for specifications.

Parm 2: initFrameset

Purpose

Frameset containing initFrame into which initIam is to be loaded.

Status

Required

Type

String

Details

See init() ^script parm 3 for specifications.

Parm 3: initFrame

Purpose

Frame of initFrameset into which initIam is to be loaded.

Status

Required

Type

String

Details

See init() ^script parm 2 for specifications.

Parm 4: initIam

Purpose

Address of page to initialize and load.

Status

Required

Type

String

Details

need details.

Parm 5: initSpr

Purpose

Address of page to initialize and load in the event of a single page request.

Status

Optional Value

Type

String

Details

need details.

Parm 6: initType

Purpose

Address of page to initialize and load in the event of a single page request.

Status

Optional Value

Type

Integer

Details

See init() ^script parm 5 for specifications.

Parm 7: todoitQpageGroupOverride

Purpose

An imprecise classification of the group of pages to which the page belongs.

Status

Optional

Type

String

Details

See todoitQ1() ^script parm 9 for specifications.

Parm 8: todoitQPageTitleOverride

Purpose

The title of the page.

Status

Optional

Type

String

Details

See todoitQ1() ^script parm 10 for specifications.

Parm 9: todoitQPageFuncOverride

Purpose

A broad classification as to the function of the page.

Status

Optional

Type

String

Details

See todoitQ1() ^script parm 11 for specifications.

Parm 10: todoitQPageLevelOverride

Purpose

An imprecise classification as to the complexity of the page.

Status

Optional

Type

Integer

Details

See todoitQ1() ^script parm 12 for specifications.

Parm 11: todoitQPageIconOverride

Purpose

An icon to display after the hyperlink is displayed.

Status

Optional

Type

Icons

Details

See todoitQ1() ^script parm 13 for specifications.

Parm 12: todoitQPageIconAltOverride

Purpose

alt text to display when one mouseovers todoitQPageIcon ^{parm 7} above.

Status

Optional

Type

Text

Details

See todoitQ1() ^script parm 14 for specifications.

Parm 13: debug

Purpose

For debugging the initial integration of a page into the AEDOK Suitetm of Websites & Domains.

Status

Optional

Type

Integer

Details

See todoitQ1() ^script parm 15 for specifications.

Parm 14: iam

Purpose

For debugging the initial integration of a page into the AEDOK Suitetm of Websites & Domains.

Status

Optional

Type

String

Details

See init() ^script parm 16 for specifications.

End

FOOTNOTE

Scripts Required: todoitQ1()

todoitQ1 ( func , preTags , url , todoitQpageFrameOverride , click , mouse , textOrImage1 , textOrImage2 , todoitQpageGroupOverride , todoitQpageTitleOverride , todoitQpageFuncOverride , todoitQpageLevelOverride , todoitQpageIconOverride , todoitQpageIconAltOverride , debug , caller );

Parm 1: func

Purpose

Function to be performed.

Status

Optional Value

Type

String

Format

Specific

Values

Action

Default

null

Perform standard queing and spawning.

Values

End

Discuss

At this time there is only one value, null, which specifies to do a standard queing and spawning.

Note

The parameter was created to provide for future expansion. For now, spec null.

Parm 2: preTags

Purpose

Text to be placed immediately before any HTML code generated.

Status

Optional Value

Type

String

Format

Free

HTML compatible text.

Default

null

Do nothing extra.

Discuss

For full integration of a page into the AEDOK Suitetm of Websites & Domains, to provide the functionality of the todoitQtm and spawntm controls, all hyperlink references must be replaced by todoitQ1() script calls. But part of the functionality of the todoitQ1() script is to generate a standard hyperlink reference so that the user sees no difference in content.

These script references are invisible to the user, except for the improved user experience afforded him through the queueing and spawning functionalities.

But it is conceivable, with numerous browsers each with numerous versions, collectively countless bugs and idiosyncrasies, that the script tag pair itself ( < script > .. < /script > ) might interfere.

The preTags parm is a precautionary parm created to hopefully circumvent any such problems should they arise, by taking text (including HTML tags) which was immediately before the original hyperlink reference, but which is now separated by the script tag, and by passing it as a parameter, allow todoitQ1() to place said text immediately in front of the hyperlink reference it generates.

Note

To date, we have not needed to use this parm. If you find a need for it, please notify us, so that we may update these instructions for the benefit of all AEDOK Level 4 Active Members.

Parm 3: url

Purpose

url to load.

Status

Otional

Type

String

Format

page-relative address

Form 1

relative url

Descript

For specifying the url that would have been the url in the hyperlink replaced bytodoitQ1().

Eg 1 real

Standard Render

This anecdote, and it's attendant discussion, may provide some illumination. Snail mail version of eMail clutter.

Standard Code

This anecdote, and it's attendant discussion, may provide some illumination. < a href="../all/all_all__K(tm)_anecdote_snail-mail_clutter.html" target="f=main_adm" >Snail mail version of eMail clutter.< /a >

todoitQ1() code

This anecdote, and it's attendant discussion, may provide some illumination.
< script >todoitQ1("","", "../all/all_all__K(tm)_anecdote_snail-mail_clutter.html" ,"", 1,1, "Snail mail version of eMail clutter","","","","K(tm)",3,"~","Deadend",0,iam);< /script >

todoitQ1() Render

This anecdote, and it's attendant discussion, may provide some illumination. Snail mail version of eMail clutter. Ktm³

Discuss

The todoitQ1() script (along with the todoitQ2() script) provides the interface to the todoitQtm and spawntm controls functionality. But it also does more.

The reason the size of the code is about twice as large as the standard code, is because there is a lot more going on. In fact, the todoitQ1() script does more than twice as much in about the same amount of code.

Draw your attention to the 1,1, specs. This is the click and mouse parm pair. These will be discussed completely in due course, below, but here notice that these four characters allow one to turn on or off independently the hyperlink for either clicking our mouseovering.

In fact, the standard HTML onmouseover which activates mouseover functionality, doesn't even directly accept a URL. it requires a script, which one must write, to which one must pass another copy of the URL (requiring more characters and fodder for typos), which must then do a window.open or window.location (to execute the equivalent href). Furthermore, one must again specify the destination frame, since the href and the mouseover components of the HTML a tag appear to be unconnected.

Form 2

null

Descript

For reloading page on user click..

Eg 1

< script> todoitQ1( "", "", "" ); < /script>

Discuss

Spec a null( "" ) value for url, instructs todoitQ2() script to create a reference to the same page, which upon user click (but not mouseover) reloads the page.

Form 3

void

Descript

For display of the current directory on user click as per href="" conventions.

Eg 1

< script> todoitQ1( "", "" ); < /script>

Discuss

Omitting url instructs todoitQ2() script to create a null( "" ) href reference, which upon user click (but not mouseover) displays directory in which page is located.

Note

Said reference does not pass thru todoitQtm or spawntm controls at this time. In future it shall.

This can only be accomplished by omitting the url parm which implies all subsequent parms must also be omitted. If you spec null( "" ) instead, you would be utilizing form 2 ^above which reloads the page.

Therefore any instructions you would issue must be done before or after the todoitQ2() script reference, not within textOrImage1 or textOrImage2 which don't exist.

Parm 4: todoitQpageFrameOverride

Purpose

Frame into which url is to be loaded.

Function
ality

Override todoitQ2() ^script todoitQpageFrameOverride ^{parm 2}, which itself overrides initLoadYYMMDD() ^script initFrame ^{parm 3} (or init() ^script initToFrame ^{parm 2}).

Status

Optional

Type

String

Format

frame name

Form

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

Descript

The todoitQpageFrameOverride overrides todoitQ2() ^script todoitQpageFrameOverride ^{parm 2}, which itself overrides initLoadYYMMDD() ^script initFrame ^{parm 3} (or init() ^script initToFrame ^{parm 2}), these last two(2) being the default single page request frame specification into which the url is to be loaded.

Default

null

Do not override todoitQ2() setting of same name.

Discuss

To understand the default sequence overrides of the frame into which a url is to be loaded, we start with the single page request, the static situation.

In a single page request, AEDOK Dimensions tm loads the page into the frame specified in initToFrame ^{parm 2} of init() script if used, and into initFrame ^{parm 3} of initLoadYYMMDD() script or initFrameYYMMDD() if used.

However, in a dynamic situation whereby a user has activated a link at your website, the todoitQ2() script, which is placed shortly after the init() ^group, takes over. One can thru it optionally specify the frame into which the page in which it is contained is to be loaded in this dynamic situation. The parm is of the same name as the parm in this script, namely todoitQpageFrameOverride.

This script todoitq1() then uses that override if specified (otherwise uses the init() spec) unless this parm todoitQpageFrameOverride is spec. So, this todoitQpageFrameOverride overrides any of the prior thus allowing you to control, at the actual point of reference, the frame into which the page should be loaded.

But note that this also allows you to conveniently default to a standard dynamic context which you have pre-defined by todoitQ2() script, or if not, allows you to default to the static context which you have also pre-defined by the init() ^group.

Eg 1

A common usage.

Standard Render

This would be a common usage.

Standard Code

This would be a < a href= "pageInSameDir.html" target="f=main_adm" >common < /a > usage.

todoitQ1() code

This would be a
< script >todoitQ1("","","pageInSameDir.html", "", 1,1,"common");< /script >
usage.

todoitQ1() Render

This would be a common usage.

Discuss

In the case of a more common reference, whereby a page is simply linking to another, possibly the next, one can see that the code required is nearly as simple as a standard hyperlink, but still retains the richness of easy specification of click or mouseover.

In this example, we have defaulted the frame or target, which keep in mind is not necessarily self as would be with a standard hyperlink. See discussion of defaults, above.

Parm 5: click

Purpose

Perform the hyperlink on a user click.

Status

Optional

Type

Integer

Format

Specific

Values

Action

Do not perform hyperlink on click.

Default

Perform hyperlink on click.

Values

End

Discuss

Setting to 1 performs a standard hyperlink reference on click. Setting to 0 deactivates the onclick functionality.

One might want a hyperlink to be inactive for a number of reasons. First, the page to which it refers bay not yet exist or may be in limbo. Second, some functionality is based upon settings and buttons that have been set, pushed and clicked. The specific functionality activated by said link may be in the off or deactivated mode.

Used in combination with mouse ^{parm 6} to achieve desired result.

Note

The default is 1, thus on. Thus allowing one to skip the parm entirely if none thereafter are required. Eventually, there shall be options for this in user preferences, settings and controls.

But if this parm is defaulted, that means that there are no parms after it either which includes mouse ^{parm 6}.

So because click ^{parm 5} and mouse ^{parm 6} work together, their default ^void functionalities are discussed together here.

Defaults

Discuss

Briefly, one sentence per permutation: If neither is defaulted that is not pertinent to this discussion. If only mouse is defaulted, we set to 0, since it follows click which is not defaulted, had you wanted it on, you would have specified it so. It is not possible to have a default followed by no default. If both are in default, we make a judgement call and turn them both on; Eventually, there shall be options for this in user preferences, settings and controls.

Default
Permute

click

mouse

Action

n/a

Default

Set mouse to 0

Default

Impossible. Parms can't follow a void.

Default

Set both click and mouse to 1

Parm 6: mouse

Purpose

Perform the hyperlink on a user mouseover.

Status

Optional

Type

Integer

Format

Specific

Values

Action

Do not perform hyperlink on mouseover.

Perform hyperlink on mouseover.

Values

End

Discuss

Setting to 1 performs a standard hyperlink reference on mouseover. Setting to 0 deactivates the onmouseover functionality.

onmouseover can be an extremely power feature. It is possible to perform actions in the entire range from updating a value to loading and entire group of pages simply by having the user place the mouse over the hyperlink area.

By the term place we simply mean that the mouse has arrived. And, there are numerous other on events of HTML, such as onentry, onexit, which we intend to utilize for either enhancement or fine tuning.

Notice also we say, area. Said area includes images just like standard onclick functionality does when one uses parms textOrImage1 ^{parm 7} &textOrImage2 ^{parm 8} for incorporating images into the reference, just as one normally does with standard hyperlinks and the img tag.

AEDOK uses this feature extensively to load ancillary pages into Ktm's window ^f_main_adm at the top of the screen, without having the user need take the effort to click. Just get the mouse over there. The pages are out of the way, and so he doesn't have to close them either.

This allows the AEDOK Level 4 Active Member to provide his users and customers instantaneous information ^{some vital} that they might not otherwise click on.

AEDOK uses this technique for our info and important pages to get the required, usually small pages, immediately to the user with out his having to got thru the help-search, help-me-search irritating experience, simply by mouseovering our info symbol

and important symbol

These symbols are images of characters, not the characters themselves. Therefore we shall be able to refine them and have subtle variations upon them as time passes. These shall be discussed in detail at todoitQpageIconOverride ^{parm 13}& todoitQpageIconAltOverride ^{parm 14}.

Of course, sometime the onmouseover can be an annoyance or disaster if pages are loading left and right upon one another! Discretion is often in order.

Used in combination with click ^{parm 5} to achieve desired results.

Defaults

Note

The default depends upon click ^{parm 5}. Because click ^{parm 5} and mouse ^{parm 6} work together, their default ^void functionalities are discussed together at click ^{parm 5} defaults discussion above.

Parm 7: textOrImage1

Purpose

Text or image portion of a hyperlink upon which a user clicks or mouseovers.

Status

Optional

Type

String

Format

Free

Discuss

Because textOrImage1 and textOrImage2 work together, their functionalities are discussed together here.

textOrImage1 is generally the text portion of a hyperlink upon which a user clicks, including HTML tags that would normally be permitted.

textOrImage2 is generally the image portion of a hyperlink upon which a user traditionally may or may not be permitted to click, including HTML tags that would normally be permitted.

The reason two fields are provided is because todoitQ1() was not designed with the intention of replacing the standard hyperlink. It was designed with the intention of providing the queuing and spawning capabilities of which we often speak. To do so, due actually to vast limitations on the flexibility of specification, it was necessary to replace the direct hyperlink reference. So it's a matter of cause and effect, not direct intent.

The standard HTML hyperlink as it is created does have tremendous flexibility regarding text and image intermingling however. So in order to avoid erecting inadvertent barriers or impediments to these flexibilities, we saw fit to include two parameters which work together as follows:

In the permutations next, we shall refer to the Ktm indicators, including info and imp et all, as the Ktm functionalities.

Permute

TOI 1
Spec

TOI 2
Spec

No direct hyperlink is generated. But Ktm functionalities are dealt with according to the specs in parms todoitQpageIconOverride ^{parm 13}& todoitQpageIconAltOverride ^{parm 14}, which themselves do have hyperlinks as discussed below.

Yes

A hyperlink is generated using textOrImage2, followed by Ktm functionalities. If one did not want it so, he could have put that textOrImage2 information after the Q1 call.

Yes

A hyperlink is generated using textOrImage1, followed by Ktm functionalities.

Yes

t A hyperlink is generated using textOrImage1, followed by Ktm functionalities, followed by textOrImage2 with no hyperlink. If one wanted the hyperlink on an image he could put that image information in textOrImage1.

Defaults

Discuss

Because textOrImage1 and textOrImage2 work together, their defaults are discussed together here.

Sometimes, with a just a little bit of creativity one can with simplicity and ease introduce very useful functionality. Of course, one must always be aware of arrogance which is blindsitghing. Such as for example earlier versions of Android which insist upon placing a blank before and after everything one pastes with no option to suppress it. A functionality which requires at least 4 times as much effort per event to get rid of the undesired blanks than it takes to simply tap the spacebar when desired. In such cases, a so-called functionality becomes a massive burden. That is why eventually, there shall be options for this in user preferences, settings and controls.

Now, in the situation where neither textOrImage1 nor textOrImage2 are spec, there would be no reason to generate a hyperlink, because there is nothing to link. But there is a common expression: click here.

So, if neither textOrImage1 nor textOrImage2 is spec and click is on either by spec or default, then textOrImage1 is set to click here.

But if only mouse is on then textOrImage1 is set to mouseover here.

Default
Permute

Click

Mouse

Set textOrImage1 To

n/a

Yes

mouseover here

Yes

click here

Yes

click here

Parm 8: textOrImage2

Purpose

Text or image portion of a hyperlink upon which a user clicks or mouseovers.

Status

Optional

Type

String

Format

Free

Discuss

Because textOrImage1 and textOrImage2 work together, their functionalities are discussed together at textOrImage1 ^{parm 7} discussion above.

Defaults

Because textOrImage1 and textOrImage2 work together, their defaults are discussed together at textOrImage1 ^{parm 7} defaults discussion above.

In the following, though many of the parms discussed end with the suffix override, we often refer to them without this suffix, and it is to be understood that the meaning is the result after any and all applicable overrides have been applied.

The parms themselves are overrides if they end with the suffix override, but they are overrides to values that exist independently coming into the script even if the script does not have that particular override specified. The script then uses the resultant value, overridden or not.

And to reiterate a common usage: The term spec means specified and unless the term spec null is used, spec non-null is intended.

Parm 9: todoitQpageGroupOverride

Purpose

An imprecise classification of the group of pages to which the page belongs.

Function
ality

Override todoitQ2() ^script todoitQpageGroupOverride ^{parm 3}, which itself overrides initLoadYYMMDD() ^script initPageGroup ^{parm 7}.

Status

Optional

Type

String

Format

Specific

Form 1

initLoad YYMMDD() Form

Values As Indicated

Values

Meaning

suite

Pages pertaining to the integration of your subdomain into the AEDOK Suitetm of Websites & Domains.

map

Pages pertaining to a map of your subdomain and website as according to the common meaning of the word map.

about

Pages about your subdomain and website as according to the common meaning of the word about.

help

Pages pertaining to help at your subdomain and website as according to the common meaning of the word help.

user

Pages pertaining to users of your subdomain and website as according to the common meaning of the word user.

member

Pages pertaining to members of your subdomain and website as according to the common meaning of the word member.

content

Pages pertaining to content of your subdomain and website as according to the common meaning of the word content.

Values

End

Descript

The todoitQpageGroupOverride, form 1, with any of the specific values indicated above, overrides the specification of the same name of todoitQ2() ^script todoitQpageGroupOverride ^{parm 3}, which itself overrides initLoadYYMMDD() ^script initPageGroup ^{parm 7}, being the default single page request PageGroup.

Discuss

The pageGroup, form 1 is a loose classification of a page according to a fairly broad but sometimes contextually specific interpretation and intent as to the page's general functionality.

Indeed, one of the reasons we designed todoitQ2() script to override initLoadYYMMDD() script and todoitQ1() script override todoitQ2() script is because some pages can pertain to more than one group, depending upon context. This parameter allows one to make the proper specification.

But Ktm uses it only for such things as page theme, layout, and placement of common links, to provide a uniform user experience across the AEDOK Suitetm of Websites & Domains for any particular group, so erroneous classification has no dire consequences.

Finally, one need only respect these settings for the higher levels again, for uniformity, but once your pages have reached the lower level of content, you can override the Ktm theme settings with your own CSS.

Default

null

Do not override todoitQ2() setting of same name ^{parm 3}.

Default
In Q2()

null

Do not override initPageGroup ^{parm 7}.

Default
In Init()

There is no default, because one should make a decision in order to facilitate our efforts for uniform user experience regarding the higher level pages.

But not to worry, if you fail to specify it at that time, an alert will be issued itemizing your choices.

If you can't decide, its most likely because you are into your own content, so so simply specify content, which is Ktm's most innocuous format, and let your own creativity and inspiration take you from there.

Form 2

initFrame YYMMDD() Form

Values Beginning With group

Values

Meaning

Propagate

groupSpr

single page request group

groupSprAll

groupDc

dynamic common group

Yes

groupDs

dynamic specific group

groupDsname

dynamic specific arbitrary group

Yes

groupname

any arbitrary group

Yes

Values

End

Descript

The todoitQpageGroupOverride, form 2 overrides the specification of the same name of todoitQ2() ^script todoitQpageGroupOverride ^{parm 3}. But todoitQ2() does not override initLoadYYMMDD() ^script initPageGroup ^{parm 7}, because initLoadYYMMDD() is a form 1 spec, being the default single page request PageGroup.

Discuss

The pageGroup form 2 is a precise classification of a page according to a fairly strict interpretation and intent as to the page's inclusion in the group.

pageGroup form 1 begins in initLoadYYMMDD(), passes thru todoitQ2(), and receives it's final value here in todoitQ1().

pageGroup form 2 begins in initFrameYYMMDD(), passes thru todoitQ2(), and receives it's final value here in todoitQ1().

Note

Since both pageGroup form 1 and pageGroup form 2 utilize the same parameter fields, there is a theoretical possibility of a conflict in specifications, but since form 1 is not yet fully implemented, we do not know. But let us continue with the discussion.

Thorough
Discuss

The
three(3)
contexts
that can
exist at
any time
for any
web page

The purpose of pageGroup form 2 is to facilitate group loading of pages. And, there are at least three(3) contexts which progress from the first thru the third and can produce any number of complex intertwined scenarios. A thorough discussion has been presented earlier in our definition of the term on thru the analysis and our bullfrog discussion, ending with its own summary, all being quite lengthy but, as said, thorough.

Concise
Discuss

The
three(3)
contexts
that can
exist at
any time
for any
web page

The purpose of pageGroup form 2 is to facilitate group loading of pages. And, there are at least three(3) contexts which progress from the first thru the third and can produce any number of complex intertwined scenarios.

The three(3) contexts are as follows.
Single Page Request context
Dynamic Common context
Dynamic Specific context

Concise
Discuss

single
page
request

context

It begins with the single page request context. A user has entered the website/subdomain, usually thru a search engine or book mark reference, but even a direct reference to the website itself produces the initial single page request for index.html, or something similar.

In this initial context, one needs to establish the website itself. The framing, the backgrounds, the motif, the entire ambiance.

To do this, initLoadYYMMDD() loads the initial frameset but it needs to know which framset, etc, to load. This is all specified in the initLoadYYMMDD() specs of the page that is the subject of this initial single page request.

In these specs should contain all the information required to layout what one wants the user to see upon entering the website. Bear in mind that the page referenced may be some innocuous insignificant page, so the initial presentation is not based solely upon what is the page in question, but, again, what is desired to present to the user when he has referenced the page in question.

Each page has it's own single page request context and the AEDOKtm Dimensions tm v 1.0 Web Publishing Platform has provisions for specifying that context within each page, but many pages can spec the same single page request context.

To reiterate, upon a single page request you may desire to move a significant page from where it is usually resented to a different frame to present a silghtly different view than would normally occur.

Or, you may desire to totally replace an insignificant page with more important, "This is who we are, thanks for visiting" - type pages. You may want to display personal or business references, or credentials.

Concise
Discuss

Dynamic
Common

context

Concise
Discuss

Dynamic
Specific

context

The single page request context ^{discussed above} is static for any given page. Everyone has entered from outside. But, once the user has entered the website/subdomain, it is a dynamic situation. But there are two(2) types of dynamic situations, towit: the common, and the specific.

Here we shall discuss the dynamic specific.

The dynamic specific context concerns things that are specific to a given page in a specific dynamic context or situation. It can not be determined a priori, but rather, must be ascertained at the point of the hyperlink reference. That location defines with certainty the specific dynamic situation.

It could be a sort of intellectual drilling down process. At any specific point, you may want to do more than just load a page. You may want to change the appearance of the display, either subtly, or dramatically.

So when the page is loaded, it's dynamic specific context, it's total ambiance is automatically loaded.

We have however, broken the dynamic specific context into three(3) classes of groups for the purpose of propagation to be discussed next, towit:
groupDs
groupDsname
groupname

Propagation

When a page is loaded that has pageGroup form 2 specs that requires another page be loaded, that other ^next page may also have pageGroup form 2 specs of it's own. Whether or not to honor those specs is the form of propagation with which we are here concerned.

Values

Analysis

Propagate

groupSpr

single page request group

groupSprAll

Propagate

The single page request group can be defined for any page, but the specs apply really only to itself, ie., it's single page request context. Therefore it is contradictory to propagate forward from groupSpr.

However, it still seems possible that there might be specific instances where one might want to do something like that. So we propagate forward the groupSprAll. And, any spec having groupSprAll shall be honored.

groupDc

dynamic common group

Yes

Propagate

The dynamic common group is concerned with pages that are need for support ^{so to speak}. Therefore it makes sense to propagate forward from groupDc.

However, it still seems possible that there might be specific instances where one might want to not do something like that. So we propagate forward the groupDc. But, if any conflicts arise, spec groupDc~ in this todoitQ1() ^script todoitQpageGroupOverride ^{parm 9} to cancel this propagation. Ie., groupDc followed by the tildi( ~ ).

groupDs

dynamic specific group

Propagate

The dynamic specific group is concerned with specific contexts, but the group name itself is general. It is a quicky name so that for a given page one may spec a group of specific pages. Therefore all manor of chaos may ensue by propagating forward from groupDs.

So we do not propagate forward the groupDs. But, if any unnecessary omissions arise, spec groupDs! in this todoitQ1() ^script todoitQpageGroupOverride ^{parm 9} to continue this propagation. Ie., groupDs followed by the exclaim( ! ).

groupDsname

dynamic specific arbitrary group

Yes

Propagate

The dynamic specific arbitrary group is concerned with specific contexts, and the group name itself is specific. Therefore it makes sense to propagate forward from groupDsname.

So we propagate forward the groupDsname. But, if any conflicts arise, spec groupDsname~ in this todoitQ1() ^script todoitQpageGroupOverride ^{parm 9} to cancel this propagation. Ie., groupDsname followed by the tildi( ~ ).

groupname

any arbitrary group

Yes

Propagate

The any arbitrary group is concerned with specific contexts, and the group name itself is specific. Therefore it makes sense to propagate forward from groupname.

So we propagate forward the groupname. But, if any conflicts arise, spec groupname~ in this todoitQ1() ^script todoitQpageGroupOverride ^{parm 9} to cancel this propagation. Ie., groupname followed by the tildi( ~ ).

Values

End

Default

null

Form 2 has no default. So a spec of null is interpreted as a form 1 default, towit: Do not override todoitQ2() setting of same name ^{parm 3}.

Parm 10: todoitQPageTitleOverride

Purpose

The title of the page.

Function
ality

Override todoitQ2() ^script todoitQPageTitleOverride ^{parm 4}, which itself overrides initLoadYYMMDD() ^script initPageTitle ^{parm 8}.

Status

Optional

Type

String

Format

Free

Form

Case-sensitive alphanumeric( a-z , A-Z , 0-9 ), dash( - ), and underscore( _ ).

Descript

The todoitQ2() ^script todoitQPageTitleOverride ^{parm 4}, which itself overrides initLoadYYMMDD() ^script initPageTitle ^{parm 8}, being the default single page request PageTitle.

Discuss

The PageTitle is your chosen title of the page

Ktm displays PageTitle in our standard pager header along with navigation controls and other items that will evolve over time and eventually shall produce an index there from.

Note

The Ktm PageTitle style in our standard pager header may not be suitable for or may conflict with your content pages. Eventually we shall provide options for display affording you greater flexibility.

But if our display of the PageTitle in our standard pager header conflicts with your style or motif, continue to spec the title, but terminate the PageTitle with a tildi( ~ ) to disable it's display. Ie., PageTitle followed by the tildi( ~ ), thus: PageTitle~. The AEDOKtm standard header shall still be displayed with various navigation functionality thus maintaining uniform of functionality throughout the AEDOK Suitetm of Websites & Domains, but the PageTitle will be omitted thus affording your ability to set your own title style and format.

This is only for content pages over which AEDOK strives to afford you as much control as possible. The other pages types however, should be of our standard format, again, giving the user a feeling of continuity throughout the AEDOK Suitetm of Websites & Domains.

Default

null

Do not override todoitQ2() setting of same name ^{parm 4}.

Default
In Q2()

null

Do not override initPageTitle ^{parm 8}.

Default
In Init()

Null. But, you should decide upon a title for said page based on your own naming conventions.

Parm 11: todoitQPageFuncOverride

Purpose

A broad classification as to the function of the page.

Function
ality

Override todoitQ2() ^script todoitQPageFuncOverride ^{parm 5}, which itself overrides initLoadYYMMDD() ^script initPageFunc ^{parm 9}.

Status

Optional

Type

String

Format

Specific

Values

Meaning

For examples, click the eg. in the catagory.

Direct Reference
(External Or Internal)
Page Types.

These are pages with special addressing requirements according to the format of the address as specified in the individual catagory listed.

http

A page either outside or within the AEDOK Suitetm of Websites & Domains, but referenced with an absolute address, using complete HTTP protocol beginning with the http, thus: http://, or https://, etc.

domain

A page within the AEDOK Suitetm of Websites & Domains, but referenced with an absolute address, using HTTP protocol but omitting the http so beginning with the lowest level subdomain, thus: knowItAll.edu.aedok.com.

Ktm Theme / Formatting Page Types

All the normal pages that concern one in the creation of his website.

controls

A page containing primarily controls, widgets, tools, buttons, and gadgets. eg.

func

A page performing primarily system or support functions, such as accounting, logging in, signing up (but not forms). These pages are often viewed by users, but individual ones might never be viewed by users or may never be viewed by anyone if they load in background frames. But they still need a common theme.

A top level menu very often having general introductions, and often leading to submenus ^next, Need eg.

submenu

A submenu, usually more concise and sometimes long ^{by count}, sprouting from a menu ^prior, Need eg.

intro

An introduction to a section, subsection, topic, or just about anything often sprouting from a menu or submenu, and often leading to detail ^next, eg.

detail

A detailed presentation following an introduction^prior, but still not being actual content though it most likely leads to content ^below, eg. this page.

form

An html or other form, often sprouting from a menu, submenu, introduction, or detail ^above, Need eg.

content

Your work product, your intellectual creations, eg.

promo

Not quite an advertisement, but your own promotion of some form such as a synopsis of a book, announcement of an upcoming event, or a soon to be added subsection to your subdomain and website, eg.

K(tm)

A footnote, paragraph, diversion, anecdote, support, or ancillary document, sprouting from anywhere, and often but not necessarily destined for Ktm's window ^f_main_adm eg.

If K(tm) is spec, then K(tm) will be displayed at the tail of the hyperlink as a convenient indicator for the user, thus:
An example Ktm

If additionally, todoitQPageLevel ^{parm 12 after application} is spec and greater than or equal to the value 2, then todoitQPageLevel is displayed immediately after the K(tm), other wise it is omitted to avoid clutter

, thus:
An example Ktm2

If additionally, todoitQPageIcon ^{parm 13 after application} is spec and is deadend( ~ ), or spawn_over_self( ~~ ), then whichever is displayed immediately thereafter, thus:
An example Ktm2
An example Ktm2

If finally, todoitQPageIcon ^{parm 13 after application} is spec and is inf( ? ), imp( ! ), or ref( * ), then whichever is displayed at the tail of the hyperlink, but K(tm) and todoitQPageLevel are suppressed, again to avoid clutter, thus:
An example

An example

Note: Our spawn_over_self(

) is preliminary.

K(tm)_notice

A notice or notification to a user or customer, eg.

All External Advertizements.

Pages in which neither AEDOK nor a AEDOK Level 4 Active Member can insert a todoitQtm script.

ads1

Highest quality external advertisements.

ads2

Secondary quality external advertisements.

adsExternal

Miscl external advertisements.

Values

End

Descript

The todoitQ2() ^script todoitQPageFuncOverride ^{parm 5}, which itself overrides initLoadYYMMDD() ^script initPageFunc ^{parm 9}, being the default single page request PageFunc.

Discuss

The pageFunc is difficult to quantify, because it's not based strictly upon functionality. There are three(3) groups, though it is not important to remember them. Just select from the above values. We're simply explaining it here so you won't wonder why we have such an unusual collection, so won't give many details. Clarifications are given in the itemization where necessary, not in this general discussion. For examples, click the eg. in the value meaning.

The first group deals with special requirements for addressing,. This includes http and domain.

The second group deals with Ktm theme and formatting. The main purpose of this parm. This includes everything from controls thru K(tm)_notice.

The third and final group deals once again with addressing concerns. This includes all the external advertisements. Pages who's content neither AEDOK nor you, the AEDOK Level 4 Active Member can control.

Although upon first observation these three groups appear disparate, Upon closer examination one can see a gradient which extends from the very first to the very last.

Default

null

Do not override todoitQ2() setting of same name ^{parm 5}.

Default
In Q2()

null

Do not override initPageFunc ^{parm 9}.

Default
In Init()

Null. But, you must decide upon a func in init() for said page so that todoitQtm, spawntm controls and Ktm can properly process them.

Parm 12: todoitQPageLevelOverride

Purpose

An imprecise classification as to the complexity of the page.

Function
ality

Override todoitQ2() ^script todoitQPageLevelOverride ^{parm 6}, which itself overrides initLoadYYMMDD() ^script initPageFunc ^{parm 10}.

Status

Optional

Type

Integer

Format

Specific

Values

Meaning

Default

A sentence or short paragraph.

A #1 followed by brief analysis.

A a more comprehensive yet still concise analysis.

A a lengthy analysis can go anywhere intellectually.

Values

End

Discuss

A pageLevel is a simple indication of the level of complexity of a page which is a diversion from the topic under discussion. It's purpose is not to weed out the lesser intellects, which is ^arrogant, but rather to advise any user in some quick blink of the eye as to how much time it might take to go on this diversion. So, the boundaries between these values are not precise nor are they critical.

The pageLevel appears after any Ktm created by todoitQ1() ^script as explained in detail in todoitQPageFuncOverride ^{parm 11}, value K(tm), above.

Simply specify an approximate level from the values shown above for the convenience of our mutual users.

Note

The default is 1, and a value of 0 or null is set to this default. But to avoid clutter, 1 is never displayed. Only 2 or greater are displayed.

Parm 13: todoitQPageIconOverride

Purpose

An icon to display after the hyperlink is displayed.

Function
ality

Override todoitQ2() ^script todoitQPageIconOverride ^{parm 7}, which itself overrides initLoadYYMMDD() ^script initPageIcon ^{parm 11}.

Status

Optional

Type

Icons

Format

Specific

Characters

Values

Meaning

A link to information about or why.

A link to important or critical information about or why.

A footnote, which we refer to as ref( * ).

A deadend link from which you can easily return.

A spawn_over_self page which clobbers current page.

Values

End

Note

In the following, though many of the parms discussed end with the suffix override, we often refer to them without this suffix, and it is to be understood that the meaning is the result after any and all applicable overrides have been applied.

And to reiterate a common usage: The term spec means specified and unless the term spec null is used, spec non-null is intended.

Values

Discuss

Value

Usage

If todoitQPageIcon ^{parm 13} is spec as the inf( ? ), then the inf( ? ) shall be displayed, visually-after todoitQPageTextOrImage1 ^{parm 7} if spec, and before todoitQPageTextOrImage2 ^{parm 8} if spec.

If inf( ? ) is displayed, it is always hyperlinked to url ^{parm 3} if spec.

If todoitQPageIconAlt ^{parm 14} is spec, it is displayed at the point of mouseover if inf( ? ) is mouseovered.

Analysis

inf( ? ) is displayed whenever logically possible and hyperlinked whenever logically possible. If url is present, inf( ? ) is linked to it as well as any textOrImage if present. In this case, it does not matter whether one clicks/mouseovers the textOrImage or clicks/mouseovers inf( ? ) since they both link to the same url, so inf( ? ) serves as a flag to draw attention to the url.

However, if neither textOrImage1 nor textOrImage2 exist, then inf( ? ) is still linked to url. So accessing inf( ? ) will result in a hyperlink action to url.

In other words, by utilizing a separate todoitQ1() ^script placement, with no text or images, one can generate a help page link from the stand alone inf( ? ).

And further, by utilizing two(2) todoitQ1() ^script placements, one with text or images the other without, one can generate a standard hyperlink reference to, let us say, some functionality, and a seperate info link to explain or describe this functionality.

If the first usage is text, such as a standard hyperlink, the second can be your description or summary regarding, thus:

This tool allows

one to quickly ...

In the above, place your mouse over the inf( ? ) image to see how the todoitQPageIconAlt^{parm 14} can be used for additional, simple, information.

If the first usage is an image, such as a button, the second can be your description or instructions for utilization, thus:

In the above, place your mouse over each of the two(2) images to see how the todoitQPageIconAlt^{parm 14} can be used for additional, simple, information.

One can spec:

todoitQClick ^{parm 5} 1 on, todoitQMouse ^{parm 6} 0 off for tools
todoitQClick ^{parm 5} 0 off, todoitQMouse ^{parm 6} 1 on for info

In this way, the user can simply flick his mouse over to the pair of icons and the tools info will immediately pop up where ever you spec, without the tools being inadvertently activated.

AEDOK recommends this technique, you decide.

Note

One can link to specific locations within pages. The technique is to first define a location in the page, using html at the location, thus:
< a name=" local_spot ">optional text< /a>
then reference it by name as the URL in a link, thus:
infoPage.html# local_spot

In the above, we used spaces( ) for visual display and clarity. In actual usage spaces( ) will cause problems. Be sure to scruntch them out (except for a name).

Discuss

By utilizing either one or two todoitQ1() ^script placements, as concisely indicated in analysis immediately above, one respectfully provides our customers with the information they need for proper and informed utilization of the functionality, without their need to go look for it.

And think about it, who would know better than we or you, what specific information they need, and precisely on what page it is located, to achieve this enlightenment. From this perspective, one can see that it is barbaric to require that the user go looking for help.

This inf( ? ) icon is perhaps the most important of all our icons to date. It's intent and purpose is to link a user directly to an answer to at least one question that logically exists at the point of placement.

We say at least one because it is naive to assume that the question that one perceives is the only question, or the only important question, at that point where the icon is placed. That would be where the other 327 best results come in (in our important discussion example below concerning requiring the user to search).

However note that is is not intended to take a user to the help section, or link a user to a help page with a search box requireing that he then search for the issue from which he just came.

If you want to link to a general help section, use todoitQPageTextOrImage1 ^{parm 7} and spec Help as well, thus:

Help

Otherwise take him to a context specific resolution.

Just don't make the user have to use a search box if he just came from the location that has all the context specific information that you know he will have to key in to maybe find the answer that you already know he is looking for because he clicked your link.

Even if it is general information, he should not have to click your link to get to a search page and then have to search for general information.

Value

Usage

The imp( ! ) behaves in the same way as inf( ? ) above.

Analysis

Analysis for imp( ! ) is identical to that of inf( ? ) above.

Discuss

Utilization of the imp( ! ) icon is similar to that of the inf( ? ). But whereas inf( ? ) is used for a range of information all the way from general operation and functionality to simple user curiosity, the imp( ! ) is used for important or even critical information, thus affording immediate direct access to this critical information.

By utilizing either one or two todoitQ1() ^script placements, as concisely indicated in inf( ? ) analysis above, one respectfully provides our customers with the information they need for proper and informed utilization of the functionality, without their need to go look for it.

If the first usage is an image, such as a button, the second can be your description or instructions for utilization including caveats.

And AEDOK intends to provide variations in perhaps color or shape of this imp( ! ) to indicate such things as whether or not the user has examined the information at the link before. This concept is similar to the standard hyperlink changing color if one has already visited it, but this usage would be more of an importance than just a convenience.

You, the AEDOK Level 4 Active Member need not worry about these enhancements when considering the placement of your imp( ! ) links because this additional functionality will be automatic.

However, due to the usefullness of this icon, it is a good idea to be ever cognizant of places where it, or its lesser inf( ? ) should be utilized. Also, in your development you may come across situations and circumstances that we have not discussed. We would appreciate any correspondence regarding these important issues.

Value

Usage

The ref( * ) behaves in the same way as inf( ? ) above.

Analysis

Although the behavior of ref( * ) is identical to that of inf( ? ) and imp( ! ) above, (eg, it suppresses Ktm), it's utilization, and therefore it's functionality, is of course different. Whereas inf( ? ) and imp( ! ) often concern themselves with issues of functionality of the website itself, ref( * ) is more inclined to be content oriented. Though this is by no means a fixed rule, since of course AEDOK uses the ref( * ) in our discussions about the AEDOK Suitetm of Websites & Domains, and you could easily find circumstances when the inf( ? ) and imp( ! ) apply to your content.

But the point is that the ref( * ) can be used just about anywhere to indicate a small, footnote type diversion which you pop up in Ktm's window ^f_main_adm.

And further, by utilizing two(2) todoitQ1() ^script placements, one with text or images the other without, one can generate a standard hyperlink reference and a seperate ref^{or footnote} link to explain or describe this link, which HTML has no provision for!

If the first usage is text, such as a standard hyperlink, the second can be your description or summary regarding, thus:

We were driving

at a leisurely pace.

In the above, place your mouse over the ref( * ) image to see how the todoitQPageIconAlt^{parm 14} can be used for additional, simple, information, which we re-itterate, HTML does not have any provision for doing.

With a standard html hyperlink the user has no idea what's out there, and you have no way to conveniently specify what is out there. And, you are already creating the hyperlink anyway. So the additional effort to spec ref( * ) and a couple extra words of text is nil compared to the service you can provide your user/customer that other web sites would have to go thru additional effort to attain.

Discuss

The reason we say small diversion is because we'd prefer you utilize the Ktm-with-level technique as explained in detail in todoitQPageFuncOverride ^{parm 11}, value K(tm), above.

By so doing, one simultaneously provides the user with useful information, just like ref( * ), and about the size of the diversion, and promotes Ktm.

Value

Usage

The deadend( ~ ) is displayed when ever spec and works with Ktm, not suppressing it.

Analysis

The deadend( ~ ) does not necessarily mean that the specific page is a deadend, but rather, that if one follow only deadend( ~ ), then he will eventually reach a deadend, not go in circles. From there he can use his back button without stumbling.

Just because one can us a back button does not mean he can't get lost. Getting lost does not have to do with just backing up. It is knowing when to stop backing up. If the forward path criss-crosses over similar pages and phrases, when one starts backing up, he won't know where he is!

It is thus a sort of green light. Eventually AEDOK shall implement a super back button which will take on back to the deadend( ~ ) event starting point.

Discuss

Of course, keep in mind that since you are spawning to alternate frames such as Ktm's window ^f_main_adm, there would usually be no need to back up anyway. So, deadend( ~ ) is just another tool.

It is most appropriately utilized when the author ^you know ahead of time that this is a divergence and that the divergence has additional divergences, but that none of these are intertwined. An intertwined example: Describing the functionality of some tool or function which itself references countless others.

But don't ignore using it simply because you are spawning to another frame. For, it may be useful in some other, later, reference to that page, possibly from the frame to which you are in this specific event spawning it.

Again remember, the specification originates in initLoadYYMMDD() ^script and concerns the nature of the page. One need only spec in todoitQ2() ^script and here todoitQ1() ^script should it need to be changed. In fact, this particular parm should not need to be changed and the only compelling reason the parm exists here is so the order and number of parms does not get scrambled, so that you would then have to figure out, "Well, do I need to spec-null this parm in this script, or is it not in the list anyway?."

But, at the risk of rambling, having said that, there are reasons why one might want to change this spec. It may be defined as deadend( ~ ) in initLoadYYMMDD() ^script but be imp( ! ) here. Just an example.

Value

Usage

The spawn_over_self( ~~ ), like deadend( ~ ), is displayed when ever spec and works with Ktm, not suppressing it.

Analysis

The spawn_over_self( ~~ ) is a companion to deadend( ~ ) and sort of opposite. It indicates to the user that this particular page containing the link he is about to click is going to be clobber by the page that he clicks to see.

Discuss

Now, this is an override situation. Any page, regardless of how it is defined in initLoadYYMMDD() ^script has the potential in a dynamic situation of clobbering the page referencing it. And in your specific context, you may have nowhere else to put it. So, in this script call, you politely warn the user with the spawn_over_self( ~~ ) icon.

Values

Discuss End

Discuss
General

With the passage of time, AEDOK intends to use icons extensively, with variations in color and shading to indicate variations on meaning. We are not the first, so we can not take credit for any great enlightenment. But we do intend to use them in an orderly manor far in excess of tradiitional usage. For example the standard minus( - ) and plus( + ) often included in faint boxes and other variations to show collapsability and expandability, shall be expaned upon to show ^{figuratively speaking}, either half empty or half full and some other variations. We discuss this in great detail [need link].

All these icons are actually images, so we shall be ably to improve their appearance and functionality as we are inspired without any impediment or hardship on the AEDOK Level 4 Active Member.

Import
Discuss

Regarding inf( ? ) and imp( ! ), we would like to diverge here a moment inline, not to another window, and expound upon the importance.

All too often a person has a question, "What is the meaning of that term?" Or, "What do they mean, it is critical to xyz the abc." One goes to the so-called help page, looks up xyz, and they proudly annunce they have 328 "Best Results", or some such term. And ABSOLUTELY NONE of them answer the question which logically had an answer in the mind of the person who wrote the statement on that specific page with a clear and specific context!

This is not a mistake, this is not an oversight, it is not an error. It is a clear, intentional, act of a slovenly I-don't-care-because-I-don't-have-to attitude.

With time, AEDOK shall develope techniques for capturing answers at the point the question is created, for they surely exist. How can one say, ".. be sure to xyz .." and not have some idea of what xyz is?

Until such time, please try to utilize the inf( ? ) icon functionality of the todoitQ1() ^script, as well as the others as appropriate, to link users as directly as possible to specific help that directly speaks to the issues at the point of the link, not some vague meandering that takes one's time but leaves one wondering "Is the answer in here? Is that it?"

The detail presented in the above Value itemizations should clearly explain how this can be easily accomplished, providing of course one already has the answer to the question which he himself is posing.

If there's any uncertainty whatsoever as to the functionality of these icons, please do not hesitate to contact us.. We truly want to help you help us build the most enlightened and functionally viable archive in existence.

Psycho

One may wonder why AEDOK pays so much attention to avoiding the back button. It is a matter of very subtle psychology.

When the page one is reading suddenly disappears, it is no longer his center of attention. He can't just flick his eyes back. He has to exert additional effort and co-ordination, and then retrain and focus.

For example, when AEDOK has someone reading our long and involved Open Invitation To The World

we are not about to deliberately clobber that page with a one line comment, so that the user can say, "Yea, this is all very interesting, but I've go to ....".

It is impossible to measure, but an astute observer realizes it is valid. Just like the traditional, and used-to-be-strictly-enforced code of silence in a library. No one ever measured how much creativity was lost from chatter, but logic and reason dictated the validity of tranquility.

There are all manor of devices and techniques one can use to gain attention, notoriety, traffic, membership, loyalty and wealth.

AEDOK desires to create a non-distracted, and thus peaceful and rewarding, learning experience. And we hope that your subdomain and website is one of these islands of a rewarding learning experience.

Note

Parm 14: todoitQPageIconAltOverride

Purpose

alt text to display when one mouseovers todoitQPageIcon ^{parm 13}.

Function
ality

Override todoitQ2() ^script todoitQPageIconAltOverride ^{parm 8}, which itself overrides initLoadYYMMDD() ^script initPageIconAlt ^{parm 12}.

Status

Optional

Type

Text

Format

Free

HTML compatible text.

icon
Values

Default initLoadYYMMDD() ^script initPageIconAlt ^{parm 12} text.

Information

Important Information

Footnote

Deadend, just follow the ~ and you will not go in circles AND you can easily return.

This link will clobber the current page, so you will need to use your back button.

Values

End

Descript

alt text is text that is displayed when a user mouseovers and image. The text is generally displayed in proximity to the mouseover point.

AEDOK icons, like most, are images thus affording the utilization of the alt text functionality. Thus you may specify useful, quickie type, information to appear at the icons mouseover point.

One first specifies an iconAlt in initLoadYYMMDD() ^script initPageIconAlt ^{parm 12}. If not spec, or spec null, initLoadYYMMDD() ^script sets to the defaults indicated above. We've not conjured up any reason one would deliberately want null, but if you do, spec a single space( ).

todoitQ2() ^script does no automatic override.

This todoitQ1() ^script does no automatic override.

Discuss

It is interesting that there is no alt equilivant for the hyperlink itself. Indeed, One of the very first motivating factors to create inf( ? ) was because inf( ? ) is an image and one can thereby utilize alt to display instantaneous at-the-mouse-point information.

Frankly, it is discusting when one thinks about it. How can a group of intellectuals who designed a great thing, the Internet and a component HTML, not see that if one wants information to describe an image, he might want information to describe a link. The functionality of such a concept is not related to the underlaying structure, is it an image or a link to an image, but rather, to what is it !

At this point, believe it or not we become speechless ...

Parm 15: debug

Purpose

For debugging the initial integration of a page into the AEDOK Suitetm of Websites & Domains.

Status

Optional

Type

Integer

Format

Specific

Values

Depth

Action

Default

Off

Off, but critical alerts shall be issued.

Detail

On. alerts at significant points as a trace.

Important

On. alerts of important or summary info.

Values

End

Discuss

Note

Parm 16: iam

Purpose

For debugging the initial integration of a page into the AEDOK Suitetm of Websites & Domains.

Status

Optional

Type

String

Format

Free

Discuss

When an alert is issued as per debug ^{parm 6} the intent is to provide tracing information within each alert so that one can follow the flow, in an environment which is otherwise implementor-hostel, as follows:

When a function is entered, a local variable iam is assigned is's name. When said function calls another function, it passes this name to that function, but adds information. When it was called, it's caller passed it's name which this function receives as the variable caller. So upon entry to a function, that function has it's own name and it's caller's name, so it sets a third local variable, iamCalleraller to the value of it's own name followed by it's caller's name, separated by a percent( % ).

This process goes on and on, so that every time a function is entered, one not only knows it's name, but who called it. Each time the list gets longer.

In a multi frame environment, and therefore multiple threads, each calling similar and/or the same functions often multiple times, otherwise one's mind is turned to putty.

For the initial call, that is for example here in init, one can place any useful text string. AEDOK generally uses the variable iam, again, which we set locally to clfUrl just before the reference to init script. In this way, the sequence is complete and guaranteed.

AEDOK recommends this technique, you decide.

End

FOOTNOTE

Scripts Required: todoitQ2()

todoitQ2 ( href , todoitQpageFrameOverride , todoitQpageGroupOverride , todoitQpageTitleOverride , todoitQpageFuncOverride , todoitQpageLevelOverride , todoitQpageIconOverride , todoitQpageIconAltOverride , debug , iam );

Parm 1: url

Purpose

Future expansion.

Status

Ignore

Type

String

Format

Spec null

Parm 2: todoitQpageFrameOverride

Purpose

Frame into which page is to be loaded for dynamic context.

Function
ality

Override initLoadYYMMDD() ^script initFrame ^{parm 3} (or init() ^script initToFrame ^{parm 2}).

Status

Optional

Type

String

Details

See todoitQ1() ^script parm of same name for specifications.

Parm 3: todoitQpageGroupOverride

Purpose

An imprecise classification of the group of pages to which the page belongs.

Function
ality

Override initLoadYYMMDD() ^script initPageGroup ^{parm 7}.

Status

Optional

Type

String

Details

See todoitQ1() ^script parm of same name for specifications.

Parm 4: todoitQPageTitleOverride

Purpose

The title of the page.

Function
ality

Override initLoadYYMMDD() ^script initPageTitle ^{parm 8}.

Status

Optional

Type

String

Details

See todoitQ1() ^script parm of same name for specifications.

Parm 5: todoitQPageFuncOverride

Purpose

A broad classification as to the function of the page.

Function
ality

Override initLoadYYMMDD() ^script initPageFunc ^{parm 9}.

Status

Optional

Type

String

Details

See todoitQ1() ^script parm of same name for specifications.

Parm 6: todoitQPageLevelOverride

Purpose

An imprecise classification as to the complexity of the page.

Function
ality

Override initLoadYYMMDD() ^script initPageFunc ^{parm 10}.

Status

Optional

Type

Integer

Details

See todoitQ1() ^script parm of same name for specifications.

Parm 7: todoitQPageIconOverride

Purpose

An icon to display after the hyperlink is displayed.

Function
ality

Override initLoadYYMMDD() ^script initPageIcon ^{parm 11}.

Status

Optional

Type

Icons

Details

See todoitQ1() ^script parm of same name for specifications.

Parm 8: todoitQPageIconAltOverride

Purpose

alt text to display when one mouseovers todoitQPageIcon ^{parm 7} above.

Function
ality

Override initLoadYYMMDD() ^script initPageIconAlt ^{parm 12}.

Status

Optional

Type

Text

Details

See todoitQ1() ^script parm of same name for specifications.

Parm 9: debug

Purpose

For debugging the initial integration of a page into the AEDOK Suitetm of Websites & Domains.

Status

Optional

Type

Integer

Details

See todoitQ1() ^script parm of same name for specifications.

Parm 10: iam

Purpose

For debugging the initial integration of a page into the AEDOK Suitetm of Websites & Domains.

Status

Optional

Type

String

Details

See todoitQ1() ^script parm of same name for specifications.

End

FOOTNOTE

What We Have Set Up For You

We have already set up for you all the initial files you need to begin your intellectual persuits as an AEDOK Ktm Level 4 Active Member subdomain and website creator, developer and publisher. There is no unpacking, unzipping, or reshuffeling required. You can get right to it.

Sort of ...

First we must review these files we have established for you and then in the step-by-step, which is the next and last section, there is just one more group of overview-intro-diversions with the intent of establishing the proper context.

Please keep in mind, that though you may be an expert in your field, this does not mean you have detailed expertise in web creation or publishing. Of course, we are not attempting to proved that here, but there are so many little things that if one does not perceive can result in literally havoc.

The information here is essential so that you do not inadvertently remove a critical file, but fortunate it is also quite simple because there is nothing critical that you have to do here. Just critical things that you don't want to do.

That's actually easy. But you should not skip this section thinking, "Ehh, it is just a list of files," because we also begin now to discuss the specific details of the integration of you web pages into the AEDOK Suitetm of Websites & Domains.

So, we proceed.

What You Should Find

In your root directory you should find the following files:

Content Root Directory: Files

Function What To Do File

Sys Support Page Leave Alone all_all__clf_load_frame.html

Website Index Change index.html

Template Page Make Copies template.html

Your work frameset Changes & Copies yourTopSub__f_spr_work.html

In your root directory you should find the following directories:

Content Root Directory: Directories

Function What To Do Direcory

Administrative Files - adm/

Art Files - adm/art/

Background Images - adm/art/bg

Buttons In The Form Of Images - adm/art/button/

Logos Replace adm/art/logo/

Image Files Of Content Nature - adm/image/

Sound Files - adm/sound/

.

Sys Support Dir Leave Alone all

All the adm/ directories except adm/art/logo/ are empty at this time and established for future use.

In your adm/art/logo/ directory you should find the following files:

Content adm/art/logo/ Directory: Files

Function What To Do File

logo Replace logo.gif

In your all/ directory you should find the following files:

Content all/ Directory: Files

Function What To Do File

Sys Support File Leave Alone all_all__js.js

An Itemized Breakdown

We shall briefly discuss each of the items in the various directories. But, in the following discussion when we say optional this does not mean that they should be casually ignored. Some of them are of course totally optional such as for example your logo. And initFrame150801() which is only used when needed.

Others are optionial in the sense that they are not absolutely essential for functioning, however, they do provide usefull functionality and we desire that your website and domain be of the highest quality and utility to our mutual customers.

In the event of, for example, time constraints, then because of their status their implementation can be delayed. But eventually, of course when otherwise appropriate, they should be implemented and utilized.

Examination: Your root directory: Files

Examination Root Directory: Files

Function What To Do File

Sys Support Page Leave Alone all_all__clf_load_frame.html

Website Index Change index.html

Template Page Make Copies template.html

Your work frameset Changes & Copies yourTopSub__f_spr_work.html

File: all_all__clf_load_frame.html

all_all__clf_load_frame.html is a critical file required for all of your web pages. Please do not disturb.

File: index.html

index.html is normally the first page a surfer would see upon entry to your website & subdomain. It is your starting point. Mold it according to your style and intent.

Normally the index contains either indexes or menus, or if it is a part of a frameset such as you are using at AEDOK, it simply contains an introduction since your indexes and menus are displayed in other pages simultaneously.

As you will see as you progress through this website construction detail, from what is called the html head of this index page you can launch numerous other pages which would be your indexes or menus. So AEDOK recommends that this index page actually be your welcome and introduction to your website & subdomain.

File: template.html

template.html is, as the name implies, a template or skeleton. It contains all the basic code and scripts you will require to establish a web page. You can simply copy it, and then change the name and specifications that we have provided to what you require. Then add your content.

It begins with a plethora of HTML tags. Yes, we are aware that some of them are arcane and possibly even discontinued.

Most of these tags are optional.

But some of them are essential such as, title, description, and keywords, which are used by major search engines, so that surfers can find your website.!

And many of them have to do with archiving your pages in archives throughout the world. Consider: You are creating intellectual documents. Once locally archived, other scholars or just curiosity seekers, will reference them through mechanisms other than prominent Internet search engines. But these documents will not be archived unless proper HTML tags are established. AEDOK must do research into this and advise you accordingly. Or, if you have knowledge concerning these things you are more than welcome to advise us accordingly.

After the HTML tags comes a reference to AEDOK's default cascading style sheets (CSS): ../all/all_all__css_default.css . This reference is required in all web pages for for maintaining uniformity of style and appearance within the AEDOK Suitetm of Websites & Domains.

The relative address it employes is the same as used by the javascript reference next and will be discussed in proper detsil in the step-by-step.

AEDOK is developing an orderly group CSS specifications, which is currently in its infancy and of which we shall advise you upon further development.

Again, we have no need nor desire to reinvent the wheel. These CSS specifications which are useful for establishing the style, theme, and ambiance of web pages throughout a site in a uniform fashion, are in fact quite tedious. Therefore, should you be aware of the existence of a pre-established group of such specifications, please advise.

After the CSS comes a reference to AEDOK's javaScripts: ../all/all_all__js.js . This reference is required in all web pages for proper integration of the page into the AEDOK Suitetm of Websites & Domains.

The relative address it employes is the same as used by the CSS reference above and will be discussed in proper detsil in the step-by-step.

After the javaScript comes a reference to the script variables: iam and spr . These variables are optional but convenient , for holding the technical name of the page for three(3) reasons. First, if one has to specify the name more than once this will ensure that it is properly spelled. Second, because the init script has a large number of arguments, by placing these variables at the left of the page, it is easy to locate the names. And third, almost the opposite, because the init script has arguments which are primarily text, these two small variables which are placed together in the argument list are easy to spot and thus help delineate points within the list.

After the script variables comes a reference to AEDOK's inityymmddLoad() script: initLoad150801() . This reference (or its lesser substitution init()) is required in all web pages for proper integration of the page into the AEDOK Suitetm of Websites & Domains.

And After the script variables and actually before the inityymmddLoad() script comes a reference to AEDOK's inityymmddFrame() script, initFrame150801() , which we mentioned out of sequence because it is optionally used in conjunction with inityymmddLoad() script, but if used must be specified before the reference to inityymmddLoad() script. This reference (which cannot be substituted by init()) is optional in all web pages for loading additional support pages into additional frames as a block load. One(1) inityymmddFrame() script reference per page and to reiterate, occurring before the inityymmddLoad() script reference.

After the init() scripts comes a few references to AEDOK's PAKITtm scripts: pakit ( "notify" ) . These references will help with maintaining proper status of the more important HTML tags mentioned above such as title, description, and keywords.

Notice that most of them are commented out with the doubleSlash( // ). We often find it convenient to include a script reference when common, comment it out, and then should it become necessary it is already specified. In this case, often when a page is being created one must stop or delay. These PAKITtm :scripts will assist you in keeping track of their various stages of development ^{once fully implemented}.

After the PAKITtm scripts comes a reference to AEDOK's todoitQtm script: todoitQ2() . This references is essential for the todoitQtm and spawn controlstm functionalities.

After the todoitQtm script comes the end of HTML head, the < /head> tag, followed by the beginning of the body indicated by the < body> tag. But notice that there is no body tag, but instead a pair of script references, to Ktm's kDisplay() script . Thse references are essential because various components of the AEDOK Dimensions tm v 1.0 Web Publishing Platform utilize certain specifications found on the body tag so the kDisplay() script generates them along with the body tag and AEDOK's uniform headings and footings.

File: yourTopSub_f_spr_work.html

yourTopSub__f_spr_work.html is the second half of a pair of nested framesets. The first half is org_edu__f_spr_main.html located in the AEDOK subdomain org_edu and which contains the logo frame ^f_main_head, Ktm's window ^f_main_adm, the info frame ^f_main_info, the copyright frame ^f_main_foot, and a couple others, plus the bulk of the website display area being represented by it's frame named f_main_work.

AEDOK's org_edu__f_spr_main.html loads your yourTopSub__f_spr_work.html into it's f_main_work thereby relinquishing control over the majority of the display area for you to utilize according to your creativity, desires, and intent, while still maintaining control over the logo and copyright, et al. You may also utilize Ktm's window ^f_main_adm, the info frame ^f_main_info.

yourTopSub__f_spr_work.html is pre arranged in a manor we won't expound upon here, but you are at liberty to redefine it, even into one single large frame, though once we have fully implemented our collapsing frame functionality that will not be necessary.

And should you require assistance in redefining it this can be achieved for a modest fee.

yourTopSub of course is your full subdomain name so that if you were knowItAll.edu.aedok.org, located in directory aedok.org/edu/knowItAll the frameset that you would see in your directory above would be

org_edu_knowItAll__f_spr_work.html which pairs with our frameset:

org_edu__f_spr_main.html

spr of course standing for single page request.

Examination: Your root directory: Directories:

Examination Root Directory: Dirs

Function What To Do Direcory

Administrative Files - adm/

Art Files - adm/art/

Background Images - adm/art/bg

Buttons In The Form Of Images - adm/art/button/

Logos Replace adm/art/logo

Image Files Of Content Nature - adm/image/

Sound Files - adm/sound

.

Sys Support Dir Leave Alone all

You will notice as we reach the end of this section that these directories we are discussing here are for the most part empty or sparse. And they shall stay that way. This because for the most part AEDOK places files in common directories to avoid the unspeakable chaos that results from multiple copies and multiple variations.

There are however instances when it is required or expedient to place files in a more local directory, ie., closer to you. Your logo, should you choose to use one, is a good example of a file that is best placed in your directory, not mixed and mingled in ours.

Directory: adm/

adm refers to administrative, those things which are generally ancillary but are needed in order to get things done.

The adm directory content should be changed only by AEDOK or upon AEDOK instructions as for example you shall shortly receive regarding the logo.

Their meanings are as follow:

adm/art/ Contains art that are not content nature like photographs, which generally are content. They may be images, or they may be other forms of art. Generally, no files are contained in adm/art/ proper, but rather, it is a subdivision.

adm/art/bg Contains background images, sometimes just a few pixels which are then stretched or repeatedly used to for the background.

adm/art/button Contains images of buttons and tools and such icons.

adm/art/logo. Contains logos, sometimes many variations on the same company or subdomain. For example our standard AEDOK 3-line rainbow image and then the 1-line, smaller footprint, version. Your logo, should you choose to use one, resides here.

adm/image Contains the context type images like the photographs.

adm/sound Contains sound files of a non-content nature, like buzzes, whistles, and click, et al.

Directory: all/

You will notice we use the word all frequently. all refers to something which applies to all sub parts.

all directory contains files which are critical for the proper integration of your website and subdomain into the AEDOK Suitetm of Websites & Domains. Please do not disturb.

Any files AEDOK requires in your subdomain should be found in these two(2) main sub-directories.

Examination: sub directories Files:

Examination: sub directories Files

Function What To Do Directory File

Administrative Files - adm/

Art Files - adm/art/

Background Images - adm/art/bg

Buttons In The Form Of Images - adm/art/button/

Logos Replace adm/art/logo/ logo.gif

Image Files Of Content Nature - adm/image/

Sound Files - adm/sound/

.

Sys Support Dir Leave Alone all all_all__js.js

All the adm/ directories except adm/art/logo/ are empty at this time and established for future use.

Directory: adm/ files

File: logo.gif

logo.gif found in adm/art/logo/should be replaced with your logo, should you choose to use one. Initially the logo is set to our knowItAll tm. Your image should be in either the gif format and 270 pixels wide by 50 pixels high, optionally transparent, or the jpg format . The name must be all lower case, ie, exactly logo.gif or logo.jpg. Our system checks for logo.gif first because they generally load a little faster than jpg. If not found it then checks for logo.jpg and that sequence may take an additional second. If that is not found it then it defaults to text, which also may take an additional second.

As stated, it may or may not be transparent depending upon whether the entire image is already colored the way you want. It is being placed on a light blue-gray background. Experimentation is the best technique if uncertain.

Further, it doesn't have to be an official logo. It could be some small imagery that promotes your subdomain and website. But be sure it doesn't clash with our Archive for Education and Dissemination Of Knowledge theme.

Finally, you don't have to use a logo and you don't have to decide right away. If no logo is indicated, in other words if AEDOK Dimensions tm can't find a file by the exact name logo.gif or logo.jpg in your directory adm/art/logo/, then it will display a default, which is currently your subdomain name. We may change that from time to time but it will always be in an attempt to promote your subdomain in the AEDOK Suitetm of Websites & Domains.

We suggest you logon right now to your subdomain to see the knowItAll tm image and where your logo would be placed. Then change the name immediately from logo.gif to logot.gif and reload the page and you should see the textualized version of which we speak.

You can set your own logo.gif or logo.jpg at any time and change it as you like. You can even change it periodically for special promotions.

Directory: all/ files

File: all_all__js.js

all_all__js.js is a critical file required for all of your web pages. Please do not disturb.

The Step By Step

OVERVIEW

In this, the final section, 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. 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.

But one final time we must first diverge to establishing the proper context.

Please keep in mind, that though you may be an expert in your field, this does not mean you have detailed expertise in web creation or publishing. Of course, we are not attempting to proved that here, but there are so many little things that if one does not perceive can result in literally havoc.

Forwarned is forearmed, or something like that.

An AEDOK Critical Opinion: Robustness

Robustness is a concept of implementing something in a forgiving manner. In a manor so that things do not have to be letter perfect. Presumably, if there are small errors, a robust system will continue forward rather than argue like an 8-year old child that has just learned to argue.

But when robustness is implemented by fools, it results in confusion and chaos.

It took mankind literally centuries to realize that in order for a person to do something correctly, he must first understand what is that correct way. It then took mankind additional centuries to realize that in order for a person to understand what is the correct way, he must be told. It then took mankind additional centuries to figure out clear and precise means of telling, ... specification, called specs.

These three(3) concepts are simple and taken for granted, but it took mankind centuries, ... centuries, to actually figure that out. Every child has to learn these things, so if follows that some first person had to figure it out and then attempt to educate the rest. But it is not just something that is realized today and tomorrow all is clear and orderly. It took centuries.

That takes us to the 20th Century.

Toward the 2nd half mankind began the tedious process of arguing with itself over failure to comply with the letter of the specifications. Like the 8-year old child.

If a single dot or tiddle was out of place, heaven forbid a word or phrase, the entire thing would be discarded. Javascript still does that sometimes.

Then there was realized the concept of robustness. That it is possible to design a system according to precise specifications, and yet should the information presented according to those precise specifications fall short of perfection, fall short of the level of precision within the specifications, then, even then, it is possible to understand sometimes all, and usually most, of what is, or has been, specified, so that those interpreting what has been specified can proceed forward as though all was specified according to the letter perfect.

A remarkable concept. Remarkable. Until implemented by fools.

Making a long story short, for there were many additional steps to arriving at where we are now, when no error is reported, not even a hint, which is common in presumably robust systems, one is constantly kept in the dark as to whether there are errors, and when something does not work as intended which is the only indication of an error that that person would receive, the process turns into a murder mystery. Essentially something has died and one has to search to find out why. And sometimes even who has died before one can even begin to search for why.

Because with additional levels of stupidity whereby there is not even an indication of incorrectness via a difference in performance or appearance, then as chief inspector Dryfuss exclaimed,

"Logic and reason are things of the past, and madness rulls!"

In these situations, one might only suspect that there is something strange going on. Something maybe not quite right. That is, if he is lucky. Otherwise he is clueless.

For example here, if you specify the creation date of a page incorrectly, you will not be given an error message. And to compound this problem, there will not be any indication that there is an error. So first you were not told that it is wrong, and in this case of creation date, there will be no indication that it is wrong from say, the performance of the page, or the appearance of the page. A search engine scanning the page was simply ignore the error. And it will not reported either. You could enter your grave and not know that a half century earlier you had incorrectly entered that creation date.

True, the creation date of a webpage has little effect upon you over all existence, but that is just an example.

And so this is what we refer to as infantile. In an attempt to create what is called a robust system, the entire society has taken great leaps backward to an intellectual level before it was realized that it is important to specify things correctly to begin with. So the system is actually designed to be stupid. It renders one speechless.

Except to say, "Be eternally vigilant."

Abbreviations

For brevity we use the following abbreviations. Regrettably, sometimes it makes the narration flow a little choppy. But it does allow for a more concise step-by-step. On first appearance some of these entries appear trivial, such as from and to and format. But when one has omitted other simple words that are normally found in a sentence, these trivial meanings can become confused. For example, does from mean "Go get it from somewhere," or look from a certain location to another location? Is format and active verb like look, telling you to do something, to format the item, because in some of these step-by-steps we are actually telling you to do something, not just philosophizing, or is it passive, meaning the format of the item is?

It is hopped that by using these abbreviation (grouped, not alphabetical) the net result is clarity, rather than confusion.

Abbreviations

Abbr Rough Meaning

spec specified, or specifically

edit use a text editor, not necessarily change something right now

comment a comment line within the text, which has a format dependent upon the specific, local, syntax

find look within the text

find something something-else find a thing that is called by another name. eg., find tag title which means: find the tag called title

from from an approximate location within the text

to to an approximate location within the text

between ... and .. in between the two(2) ..

.

format a precise spec, but not quite a syntax

form the components of the format

perfect whether or not spec must be letter perfect

.

note take notice of

meaning a quick summary without an analysis

ana a precise analysis without a discussion

confuse a point of possible confusion. should read extremely carefully

discuss a discussion, often following an ana, which pulls in related topics

diverge a discussion, often following a discuss, which can go anywhere as we often do

.

ie. the common meaning: "that is, .."

eg. the common meaning: "for example, .."

asm assume

.

Understanding some html Components

Some html components are a single item, eg., < br >, which is a line break, ie., going to the next line.

Some html components are a pair of items, eg., < title > and < /title >, which begins and end the title, eg., < title > Find It All Here < /title >, where the title is Find It All Here.

Some html components are a triplets of items, eg., < meta name="creation date" content="" >. In this case, the tag is actually meta, and there may be many unrelated meta tags, and this specific meta tag has the name as indicated in quotes( " " ) following the word name and separated therefrom by the equal( = ), in this case creation date, and the value that you are assigning to this name is to be placed between the quotes( " " ) following the word content and also separated therefrom by the equal( = ), which in this case would be the creation date.

Other html components contain even more components which we shall not get into here, for, these three(3) variations should get us thru these step-by-steps.

Some language specs are case sensitive which means upper case letters are treated as different from their corresponding lower case counterpart, thus a and A are different, and other language specs are case-insensitive which means upper case letters are treated as the same as their corresponding lower case counterpart, thus a and A are the same. If you see it one way and it works, you likely shouldn't change it unless you know it's ok, or feel like experimenting, which of course is ok if you are prepared for dysfunctional consequences.

html is case-insensitive but it might be unwise to mix case within a single tag, eg., < meTa Name="creation date" content="" > is asking for trouble. Just because it is supposed to be case-insensitive doesn't mean that the browser hasn't acquired sub-human characteristics.

Punctuation must generally be letter perfect. Do not add punctuation in order to make things more uniform, definitely not within quotes( " " ). Because:

Some specifications use the space( ), like "creation date".

Some specifications use the dash( - ), like "resource-type".

Some specifications omit punctuation and space( ), like "imagetoolbar".

The only thing of uniform consistency than one can count on is that none of them will tell you if you are in error.

There is a concept known as white space which means essentially if there is one(1) space( ) you can have two(2) or more. So if one sees spaces( ) in eg.:
iam = "pageName.html", he could spec additional spaces( ) before or after the equal( = ), thus:
iam ="pageName.html", or
iam= "pageName.html", or
iam = "pageName.html"

And if it is punctuation not within quotes( " " ), eg., again the equal( = ) in:
iam="pageName.html", one can spec space( ) even though what you see as the spec has none, just as above.

In this regard, because we use small print and for other display formatting reasons, we show spaces sometimes where you should not use them. Specifically in html tags, the textual portion of the tag should immediately follow the openBrokenBracket( < ), thus:
this<tag>
not < tag >

And don't throw in line breaks unless you know otherwise. Some specs don't care and others do. Definitely within quotes( " " ), breaking the line is a bad idea. So eg., if you have:

name = "thisPageNameIsBecommingTooLong.html", then:

name = "thisPageNameIsBecommingTooLong
.html"

won't work even though it was broken at punctuation, because it was within quotes( " " ). Whereas:

name =
"thisPageNameIsBecommingTooLong.html"

will work, at least in javascript and in our script references we discuss.

And it is also possible to break up a long script reference as we do in or examples, though sometimes it is just easier to leave it all on a single line.

The following:

initLoad150801( initTopSub, initFrameset, initFrame, initIam, initSPR, initType, initPageGroup, initPageTitle, initPageFunc, initPageLevel, initPageIcon, initPageIconAlt, oneDebug, caller );

can be broken like this:

initLoad150801(
initTopSub,
initFrameset,
initFrame,
initIam,
initSPR,
initType,
initPageGroup,
initPageTitle,
initPageFunc,
initPageLevel,
initPageIcon,
initPageIconAlt,
oneDebug,
caller
);

Or better yet:

initLoad150801(
initTopSub, initFrameset, initFrame,
initIam, initSPR, initType,
initPageGroup, initPageTitle,
initPageFunc, initPageLevel,
initPageIcon, initPageIconAlt,
oneDebug, caller
);

But again, unless you know otherwise or feel like experimenting it would be wise to avoid it.

subDomain	directory
edu.aedok.org	aedok.org/edu/
yourSubdomain.edu.aedok.org	aedok.org/edu/yourSubdomain/

*level*	domain spec
1	com
2	aedok.net
3	edu.aedok.org
4	yourSubDomain.edu.aedok.org
4	yourSubDomain.ent.aedok.net
4	qqq.edu.aedok.org
4	qqq.ent.aedok.net
5	yourSubDomain.qqq.edu.aedok.org
5	yourSubDomain.qqq.ent.aedok.net

*depth*	level	domain spec
~	1	com
~	2	aedok.net
1	3	edu.aedok.org
2	4	yourSubDomain.edu.aedok.org
2	4	yourSubDomain.ent.aedok.net
2	4	qqq.edu.aedok.org
2	4	qqq.ent.aedok.net
3	5	yourSubDomain.qqq.edu.aedok.org
3	5	yourSubDomain.qqq.ent.aedok.net

relative address	IS IT A backaround relative address?	Why?
dir1/aPage.html	No	It goes only forward
../anotherPage.html	No	It goes only backward
../dir2/aThirdPage.html	Yes	It goes back and then forward

knowItAll.edu.aedok.org IS LOCATED IN org/edu/knowItAll/
sub-domain-relative address	domain-relative address
index.html	org/edu/knowItAll/index.html
books/great_thougts.html	org/edu/knowItAll/books/great_thougts.html

FRAMESET optional
org_AEDOK__f_single-page-request_main-clf_ala_com.html
Name	Purpose	Location	Status
f_main_head	AEDOK Logo AND Your Logo	Top Left	Restricted
f_main_adm	Ktm's window. Briefer explanations.	Top Right	Use It
f_main_info	Ques, Advertisements	Far Left	Restricted
f_main_work	org_AEDOK__f_single-page-request_SE-clf_ala_com.html	Main Display Area	Use It
f_main_back	Background activities, Then refreshed with AEDOK Logo	Hidden	Rstricted
f_main_foot	Copyright, et al.	Bottom	Restricted
Note: f_main_work is always for main display OR additional framesets. The frameset in this table, org_AEDOK__f_single-page-request_main-clf_ala_com, uses it for the additional ^sub frameset org_AEDOK__f_single-page-request_SE-clf_ala_com. These two(2) nested framesets are the framesets being used for this presentation, and this page is most likely in f_SE_content, but possibly one(1) frame to the left of f_SE_content in f_SE_secondary, both frames being part of said additional-sub-frameset, here loaded into f_main_work and shown below in the next table.

Content Root Directory: Files
Function	What To Do	File
Sys Support Page	Leave Alone	all_all__clf_load_frame.html
Website Index	Change	index.html
Template Page	Make Copies	template.html
Your work frameset	Changes & Copies	yourTopSub__f_spr_work.html

Content Root Directory: Directories
Function	What To Do	Direcory
Administrative Files	-	adm/
Art Files	-	adm/art/
Background Images	-	adm/art/bg
Buttons In The Form Of Images	-	adm/art/button/
Logos	Replace	adm/art/logo/
Image Files Of Content Nature	-	adm/image/
Sound Files	-	adm/sound/
.
Sys Support Dir	Leave Alone	all

Content all/ Directory: Files
Function	What To Do	File
Sys Support File	Leave Alone	all_all__js.js

Examination Root Directory: Files
Function	What To Do	File
Sys Support Page	Leave Alone	all_all__clf_load_frame.html
Website Index	Change	index.html
Template Page	Make Copies	template.html
Your work frameset	Changes & Copies	yourTopSub__f_spr_work.html

Examination Root Directory: Dirs
Function	What To Do	Direcory
Administrative Files	-	adm/
Art Files	-	adm/art/
Background Images	-	adm/art/bg
Buttons In The Form Of Images	-	adm/art/button/
Logos	Replace	adm/art/logo
Image Files Of Content Nature	-	adm/image/
Sound Files	-	adm/sound
.
Sys Support Dir	Leave Alone	all

Abbreviations
Abbr	Rough Meaning
spec	specified, or specifically
edit	use a text editor, not necessarily change something right now
comment	a comment line within the text, which has a format dependent upon the specific, local, syntax
find	look within the text
find something something-else	find a thing that is called by another name. eg., *find tag* title** which means: find the tag called title
from	from an approximate location within the text
to	to an approximate location within the text
between ... and ..	in between the two(2) ..
.
format	a precise spec, but not quite a syntax
form	the components of the format
perfect	whether or not spec must be letter perfect
.
note	take notice of
meaning	a quick summary without an analysis
ana	a precise analysis without a discussion
confuse	a point of possible confusion. should read extremely carefully
discuss	a discussion, often following an ana, which pulls in related topics
diverge	a discussion, often following a discuss, which can go anywhere as we often do
.
ie.	the common meaning: "that is, .."
eg.	the common meaning: "for example, .."
asm	assume
.