Minor Improvements

.gitignore

@@ -1,3 +1,4 @@
+*.idea/*
 .depend
 Makefile
 config.log

centrallix-sysdoc/javascript.md

@@ -1,16 +1,18 @@
 # JavaScript in Centrallix
 
-Author: Seth Bird (Thr4wn)
+**Author**: Seth Bird (Thr4wn)
 
-Date: August 2008
+**Date**: August 2008
+
+*With slight modification for clarity by Israel Fuller (Lightning) during June, 2025.*
 
 This file was created by Seth Bird (Thr4wn) to introduce people to nuances of how centrallix handles javascript.
 
 Please edit this file if there are any mistakes.
 
-Also, online documentation can be found at http://www.centrallix.net/docs/docs.php
+Also, online documentation can be found at http://www.centrallix.net/docs/docs.php.
 
-See serverside_html_generation.txt for more information on how the server side generates javascript.
+See `serverside_html_generation.txt` for more information on how the server side generates javascript.
 
 ## Table of Contents
 - [JavaScript in Centrallix](#javascript-in-centrallix)
@@ -20,16 +22,16 @@ See serverside_html_generation.txt for more information on how the server side g
   - [Widget Initializers](#widget-initializers)
 
 ## The Async Hack
-Note that centrallix was origionally made for NetscapeNavigator 4 which did not support AJAX using xmlhttprequest. Thus, a hack was devised upon which a lot of the system is based upon. The hack works as follows: on the client side, a new iframe (or 'layer' if NS4 is the navigator) is generated which sends a request to the server. The server looks at the request, generates requested information, and returns it as normal. Note that everything HTML-related will be a full-fledged HTML page, so the client then has to take the desired parts out of the iframe and insert it into the main page where required.
+Note that centrallix was origionally made for NetscapeNavigator 4 which did not support AJAX using xmlhttprequest. Thus, a hack was devised and much of the system is now based upon it. The hack works as follows: on the client side, a new iframe (or 'layer' if NS4 is the navigator) is generated which sends a request to the server. The server looks at the request, generates requested information, and returns it as normal. Note that everything HTML-related will be a full-fledged HTML page, so the client then has to take the desired parts out of the iframe and insert it into the main page where required.
 
-note: that in NS4, a 'layer' element could served the purposes of both a div and an iframe. Thus, the term 'layer' is seen a lot in the code. So when I use the term iframe here (and elsewhere), I also mean a 'layer' for NS4 navigators.
+**Note**: In NS4, a 'layer' element could serve the purposes of both a div and an iframe so the term 'layer' is seen a lot in the code. This documentation uses the terms iframe and layer interchangeably, even though the code will use layers for NS4 navigators and iframes elsewhere.
 
-a lot of async request management is defined in htdrv_page.js.
+Much of the async request management is defined in `htdrv_page.js`.
 
 ## Client Interface Model
-Let's say that there exists some javscript class C. An initializer for that class could look like the following:
+For example, say there is some javscript class C. One might expect the initializer for such a class to look something like the following:
 
-```
+```js
 function C_init(params)
     {
     var i, c_instance;
@@ -42,18 +44,18 @@ function C_init(params)
     }
 ```
 
-However, Centrallix does not work that way; instead, it uses the Client Interface model, which makes use of the ClientInterface constructor.
+However, Centrallix uses an alternative method called the *Client Interface model*, which makes use of the ClientInterface constructor.
 
-Instead of ever directly accesing/using methods/members, Centrallix will instead make an entire "Client Interface" instance which will contain wrappers to use said methods/members. All methods (in class instances) are supposed to be accessed indirectly via these client interfaces instead of used directly.
+Instead of ever directly accesing or using methods or members, Centrallix creates a "Client Interface" instance which contains wrappers to use said methods or members. All methods in class instances can be accessed indirectly via these client interfaces.
 
-The point of a Client Interface essentially seems to be to "bind" the methods to the object instance. "Binding" can be simply done by using Prototype's 'bind' function (http://prototypejs.org/api/function/bind) which returns a function whose sole purpose is to call the wrapped function by passing a specific object as 'this'. Thus, whenever the bounded method is called, it will always be called via a wrapper that ensures that the correct 'this' pointer is being passed to the member. The Client Interface model is essentially trying to "implement" the class methods so that the instance's methods applies only to the instance itself.
+The point of a Client Interface essentially seems to be to "bind" the methods to the object instance. "Binding" can be simply done by using [Prototype's 'bind' function](http://prototypejs.org/doc/latest/language/Function/prototype/bind) which binds a provided context to a given function. When the returned function is called, its context (aka. the `this` pointer) will be the provided context. Thus, the Client Interface model essentially "implements" the class methods so that each instance's methods apply only to the instance itself.
 
-However, Centrallix does not actually ever bind the class methods to the instance. Instead, it creates a hash of functions that the coder "wants" to be bound to said instance. Then a whole slew of wrapper functions have to be called every time so that it's ensured that these "want-to-be-bound" methods actually are being bound. But how do these wrapper functions know which object is the "bounded" object of these member functions? via the 'obj' member (read below).
+However, Centrallix does not actually bind the class methods to the instance. Instead, it creates a hash of functions that the coder "wants" to be bound to said instance. Then a whole slew of wrapper functions have to be called every time so that it's ensured that these "want-to-be-bound" methods actually are being bound. But how do these wrapper functions know which object is the "bound" object of these member functions? via the 'obj' member (read below).
 
 A Client Interface instance will contain the following:
 
 * an 'obj' member which points to the object intended to be the
-    boundee
+    context
 
 * a container of all "want-to-be-bounded" methods/members
 
@@ -63,7 +65,7 @@ A Client Interface instance will contain the following:
 
 Thus, an initializer for some class C (using this model) would look like the following:
 
-```
+```js
 function C_init(params)
     {
     var obj;
@@ -80,34 +82,36 @@ function C_init(params)
     }
 ```
 
-So ultimately, instead of typing:
+So ultimately, instead of calling a function using the traditional syntax:
 
-`c_instance.changeText("foo");`
+```js
+c_instance.changeText("foo");
+```
 
-you have to type:
+You invoke it using this syntax:
 
-`c_instance.ifcProbe(ifAction).Invoke("changeText", "foo");`
+```js
+c_instance.ifcProbe(ifAction).Invoke("changeText", "foo");
+```
 
-This is what the instance would look like using the traditional
-approach:
+This is an example of an instance using the traditional approach:
 
-```
-   c_instance                    
+```js
+    c_instance                    
 +------------+                   
-|   member1 -+----> "value1"      
-|   member2 -+----> "value2"      
-|   method1 -+----> function(){} 
-|   method2 -+----> function(){} 
+|   member1 -+--> "value1"      
+|   member2 -+--> "value2"      
+|   method1 -+--> function(){} 
+|   method2 -+--> function(){} 
 | formMember-+--> ...
 | formMethod-+--> ...
 |            |                   
 +------------+
 ```
 
-This is what the instance would look like using the Client Interface
-approach:
+This is an example of an instance using the Client Interface approach:
 
-```                                           
+```js
   c_instance   <----------------------------------------------------------------<-+-<-----------------+
 +------------+                                                                    |                   |
 | member1 ---+-> ...                                             +------------+   |                   |

centrallix-sysdoc/serverside_html_generation.md

@@ -1,22 +1,40 @@
 # Serverside HTML Generation
-Author: Seth Bird (Thr4wn)
 
-Date: August 2008
+**Author**: Seth Bird (Thr4wn)
 
-This file was created by Seth Bird (Thr4wn) to introduce people to
+**Date**: August 2008
+
+*With slight modification for clarity by Israel Fuller (Lightning) during June, 2025.*
+
+This file was created by Seth Bird (Thr4wn) to introduce developers to
 nuances of how centrallix handles javascript.
 
 Please edit this file if there are any mistakes.
 
-Also, online documentation can be found at http://www.centrallix.net/docs/docs.php
-
-See javascript.txt for more information on how the javascript side of things work.
+Also, online documentation can be found at http://www.centrallix.net/docs/docs.php.
+
+See `javascript.txt` for more information about the generated javascript that is generated.
+
+## Table of Contents
+- [Serverside HTML Generation](#Serverside-HTML-Generation)
+  - [Note about Unique Endings](#note-about-unique-endings)
+  - [Server-side App handling](#server-side-app-handling)
+    - [1) Conversion of App file to internal machine data](#1-conversion-of-app-file-to-internal-machine-data)
+    - [2) Auto Positioning](#2-auto-positioning)
+    - [3) HTML generation](#3-html-generation)
+    - [Conversion to Internal Machine Data](#conversion-to-internal-machine-data)
+    - [Apos Unit (Auto Positioning)](#apos-unit-auto-positioning)
+    - [HTML generation](#html-generation)
+    - [Logical Division of html page](#logical-division-of-html-page)
+    - [Flow of server-side html generation](#flow-of-server-side-html-generation)
+  - [Misc information](#misc-information)
+    - [Server-side "Classes"](#server-side-classes)
 
 ## Note about Unique Endings
 
 You'll see the following notation:
 
-       startup_*, build_wgtr_*, expinit_*, *Render, etc
+       startup_*, build_wgtr_*, expinit_*, *Render, etc.
 
 Where * represents some unique set of letters/numbers. (explanation given below)