Here, my-style is a cached entry just defining the <body..> tag with a predefined
colorset. The user doesn't have to know the exact color definitions, it just chooses one of
a set designed by you, the provider.

The my-guestbook is a script made by you, the provider, returning the last 5 written
entries and providing a means to add new entries. The user doesn't know where the script
is stored, the script can even be executed outside of the document directory, so the
security is totally under your control. You only provide a safe restricted interface
to your modules by using these tags.

Consistency

Another important thing is that you can program your modules to use a common shared set
of variables to force a certain layout or style in the resulting html pages. In the
previous example, the my-style module could have set a global array $colors,
containing color definitions that should apply to the whole page, e.g. $colors[td_bgcolor],
$colors[td_text] etc.

Both the my-guestbook and the my-chat module can access these variables to layout their
output as well. So you can have a designer define some colorsets, fontsets etc. and the
creators of the .my files only have to enforce the design by providing a simple name in
one tag: my-style (in this case)

Implementation

Now it's time for some php. There is only ONE script needed for this, the parser. It
reads the .my files and replaces the special tags with the output from the modules, or
the cache if applicable. The parser is called by Apache redirecting all calls for .my
to this script. To do this, use the following mod_rewrite call in .htaccess:

RewriteEngine on
RewriteRule \*.html /lib/parse.php

The parser /lib/parse.php can determine which file was originally asked for
by examing the $REDIRECT_URL variable, and use this to call the parse function
which returns the parsed html:

<?php

if ($REDIRECT_URL)
echo parse ($DOCUMENT_ROOT . $REDIRECT_URL);

//The parse function just reads the file and calls parse_it for every line to build up the output in $buf: