Before starting to create a line of code, a lot of thinking was done to
create a good framework and I believe I did.

There are some specific choices I made to make the scripts easy to use and
very easy to extend, without changing the base of the code. If you would
want to, go ahead, but think of this:
- global variables are used only when needed. Mostly: $debug, $error,
	$formHandler and in the beginning $modules;
- the only things needed outside every module is it's name and (public)
	function-set. The name is set with the configuration and addressable by
	the CONSTANT that is defined in the module classfile.
- every module can be extended and dynamically replaced. This makes it
	possible to extend the module Display or Mail by creating a translated
	version or even a version that translates different languages. (see
	mailattach.mod.php)
- it is possible to add as many modules as you would like or have around
	(created). But remember that every added module can make the script
	slower. When installing the script on a slow machine (before pentium III)
	and using a lot of modules, options, etc. there can be performance
	probems. Look at README.performance.
- the only output to the screen (browser) should be from the display
	module. Furthermore, the echo command is used for (extra) debug-messaging
	and the print command for a real output command.
- All values that are not stored in a variable are set in a constant. This
	happens in the file where the value belongs to, allthough it can be used
	outside that context. Note that is necessary to keep a good record about
	these, because you may use a constant that already exists. All constants
	should, however, be defined in the first lines of a file (after some
	comments) and use CAPITALS.

Creating modules and loading dynamically.
When you want your new module to be loaded dynamically it should have a
modulename.def.xml file. Look at README.modules

Execution- or runlevels
For the execution of the modules I created a level-option. This means that
every module must define a level. The formhandler walks through the
execution-levels (in 3 levelgroups) and checks and executes the modules on
these levels (within levelsteps 10 levels).

The levels are set up to be:
0-9  Extra configuration options (no dynamic loading, only configfile.inc.php)
10-19 Used for validating
20-29 Execute (send mail, display screen, send reply, etc)

Previously there were a total of 100 levels, this is brought back to 30,
because of performance reasons.

The defined values are:
Module config: 1
Module mail: 22
Module display: 25

Display and mail need to be in the same runlevel, otherwise the defined
options can't be deleted from the vars list. All modules in runlevel 90-99
cannot have their (in the form) defined options deleted, before sending the
mail. (? don't know if this is still true, but less of a problem)

All dynamically loaded (AUTO_CONFIG _and_ via config-option or configfile)
modules should have an execlevel higher than 10, because they are added to
the runlevels in runlevel 0 (execlevel 0-9), but cannot be executed in the
same run.


Message-levels
With every message it is possible to add a message-level. There are
currently 2 kinds of messaging (maybe in the future 'Logging' will be a
new module): Error and Debug. The levels of each will be explained below.


Error-levels
With every error-message it is possible to add an error-level. Otherwise
the default error-level of 1 is added.

In the following table you can find the meaning of these levels:

0 no error: make it a debug message of level 1
define("ERR_DEBUG",1);
define("ERR_INP_CONT",2);
define("ERR_INP_END",3);
define("ERR_CONF_CONT",4);
define("ERR_CONF_END",5);
define("ERR_DEV_CONT",6);
define("ERR_DEV_END",7);
define("ERR_CRIT_CONT",8);
define("ERR_CRIT_END",9);


Debug-levels
define("DB_INIT",-1);
define("DB_ERROR",1);
define("DB_WARN",2);
define("DB_FLOW",3);
define("DB_INPUT",4);
define("DB_CONF",5);
define("DB_XFLOW",6);
define("DB_INFO",7);
define("DB_DEV",8);