Security
Another aspect of using this system is that you hide the php totally from the files,
so you can easily let ordinary users use your tags to create dynamic content without security issues:
so you can easily let ordinary users use your tags to create dynamic content without security issues:
<title>Joe's homepage</title>
<my-style name=yellow-blue>
<my-guestbook name=joe showentries=5 addtext="Please add to my guestbook" cache=0>
<my-chat room="Joe's chatroom">
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.
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.
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.
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)
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:
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:
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:
function parse ($file) {
$buf = "";
if ($f = fopen ($file, "r")) {
while ($str = fgets ($f, 4096)) {
$buf .= parse_it ($str);
}
fclose ($f);
}
return $buf;
}
?>
