Documentation Index

Site Rules

Rules

This site operates through a "rules file". There is a GET variable named op that instructs the code what to do. This is done by looking up the "operation code" and running it's list of commands (functions).

The source file RULES.PHP also validates some of the $_GET input data. See the section Validating Input below.

This "rules" thing does obfuscate execution somewhat, however, once understood you will see the reasoning behind it and it's benefits.

First, open RULES.INI; here is an excerpt:

        default = read
        [read]
        displayhtml open
        displayentries
        displaycomments
        displayhtml close
        [grok]
        displayhtml open
        displayentry
        displaycomments
        displayhtml close
        [submit]
        displaysubmit

A typical PHP website uses URL arguments (?foo=bar) to do verb stuff like "read" or "write" (well, our always seem to do). We initially had a basic if/else construct, that, and you will see the connection to the above data, was kind of like this:

        $op = (isset($_GET['op'])) ? $_GET['op'] : 'read';

        if (
$op == 'read') {
            
displayhtml('open');
            
displayentries();
            
displaycomments();
            
displayhtml('close');
        }
        elseif (
$op == 'grok') {
            
displayhtml('open');
            
displayentry();
            
displaycomments();
            
displayhtml('close');
        }
        elseif (
$op == 'submit') {
            
displaysubmit();
        }
        
        ...

And that code was right at the bottom of INDEX.PHP and changed often during initial design. There is something good to come from a lazy brain, in that by writing some extra code, we moved this "site execution array" into a more manageable data format. (And since a few of us are DOS people, an INI file came to mind; the RULES data can easily have been JSON or XML or whatever.)

There is probably some "pattern" for this concept/construct; the word "dispatcher" comes to mind... Anyway, it is just an array — an array of things to do for a command argument.

And only this file handles that array of things to do. INDEX.PHP just makes sure that the website is set up properly and then hands control over to RULES.PHP which, via data in RULES.INI, executes those "things to do".

Oh, and note that the "things to do" are functions. Functions either defined by the other code here or PHP functions. Here is one last example that should solidify this. By adding this to RULES.INI:

        [phpinfo]
        phpinfo

You have now modified your website to call the PHP phpinfo() function by a URL of example.com/?op=phpinfo.

This concept is as "old as the hills" as old people used to say (I should know, I am old); you can see it in shell scripts, batch files, many small C programs and in PERL programs. It fits right in with PHP programs.

Currently, function arguments are stringized; i.e:

        [vars]
        var_dump a b c

with ?op=vars, would result in:

        string(1) "a"
        string(1) "b"
        string(1) "c"

As soon as the need arises for something else this may change.

GET arguments are expanded:

        [test]
        var_dump $op $arg

with ?op=test, results in:

        string(4) "test"
        string(0) ""

because the arguments are space exploded and not trimmed.

Rules can now reference super globals. This is our logout rule:

        [logout]
        cookie_unset from
        redirect ?{$_POST['redirect']}

Validating Input

The RULES.PHP code validates the GET data at two different times in the load process, very early it checks for invalid or missing data. After the entire code has been loaded and initialized, but right before the site displays any output it checks passed object IDs for existence.