Ben's Web Programming PagesPlease note that these pages date from 2003 and are near prehistoric in internet terms. It was good stuff when it was written, but old hat now.
These pages not maintained and I no longer deal with queries about them. They remain here for historical interest.
I have use two methods for generating the dynamic content across the website: Perl CGI scripts, and PHP scripts.
CGI is a specification that dictates how an arbitrary program can cooperate with a webserver to produce dynamic web content. It specifies how arguments from the web browser are passed to the program, and how that program can specify HTTP headers and web page contents.
Various scripts on this site are written in Perl. Perl is the system administrator's Swiss Army Penknife: it has a tool for every occasion. For serving web-pages it runs under the web server as a CGI program. The Perl script outputs plain text to stdout: first the HTTP headers, then a blank line, then the body of the web page.
The input parameters - that is, the GET, POST and COOKIE arguments supplied by the webserver - are available to the Perl script in raw form as environment variables which need to be unpacked and decoded. This is tricky and error-prone.
Perl comes with a module called CGI.pm which provides very convenient functions for safely handling the input parameters, and for simplifying the generation of all the various web page constructs and form elements. It is a large body of code, however, and loading it can noticibly delay the generation of your web page. Considering that (depending on your server setup) it will probably need to be loaded every time your page is accessed you may prefer to do without it. The CGI.pm module does, however, simplify the management of "sticky" forms, that is, forms that retain state information between viewings. This can be laborious if done by hand.
The CGI.pm module can be persuaded to generate valid XHTML 1.0 strict (although version 2.88 has a problem with forms which I have reported to the maintainer). To do this I use code like the following,
use CGI;
my $page = new CGI;
$page->default_dtd(
'-//W3C//DTD XHTML 1.0 Strict//EN',
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd');
print $page->header,
$page->start_html( -dtd=>'yes', -title=>'Page Title');
I generally use Perl for writing small, simple pages that do relatively low-level tasks without complex output. Anything that generates a lot of HTML is probably best done in PHP.
This is a little program that generates various GIF images for the website on-the-fly. See my GIF-server page for a longer description of it and a link to the source code.
A small Perl program, file.pl allows browsers to see the source code of some of my Perl and PHP programs. Normally that would not be possible - you can only see the output of these programs - but I wanted to make the source available to some of them. It basically just substitutes HTML special characters in the source with the HTML-safe versions and sends the resulting file to stdout with a Content-Type: text/html header. Only files that are listed in the source code may be viewed with it. If the file is not available it returns a "404 Not Found" error page.
The input argument for the file-server is specified in the URL, which is available to the program as the environment variable REQUEST_URI. The last part of the URL is the file whose source code is to be viewed. So for example, http://www.edginet.org/file.pl/mcheyne/calendar.php displays the source code of http://www.edginet.org/mcheyne/calendar.php
Another little Perl utility on the site is the HTTP header viewer. It uses the
Perl IO::Socket module to establish communication with
the remote webserver.
The contact me page is written in Perl and it invokes the server's email client to send me email. It uses the CGI.pm module to create a "sticky" form which cooperates with the web browser to "remember" various parameters between invocations of the page. This does not happen automatically!
PHP is similar in some ways to Perl, but unlike Perl it is specifically designed for writing web applications. Thus it is faster and simpler for coding up dynamic web pages, and also seems to execute somewhat faster than Perl as well.
One particular advantage of PHP is that the program code can be
interspersed with HTML in an ad hoc way. Everything between
<?php and ?> markers is PHP script.
In Perl, by contrast, all of the HTML must be output explicitly which
can lead to very messy code. So with PHP you can do things like
this,
<html><head><title>The date and time</title></head><body>
<p>The current time is <?php echo date("D, M j Y G:i:s T");?></p>
</body></html>
PHP comes with a whole bunch of useful stuff for web programming, such as database access functions and cookie handling functions which can simplify the business considerably. Also PHP files do not need to be made executable, unlike Perl files.
To find out everything about how your
web-server is configured for PHP you can use the phpinfo()
function. Save the following tiny program as a file on your
web-server with a .php extension, then try to access it
with a browser. You should get a page with a whole load of nicely
formatted information about the PHP set up.
<?php phpinfo(); ?>
For security reasons you should not leave this script lying around in a publically accessible place on your server: it gives away too much.
The PHP manual can be found at http://www.php.net/docs.php
The main PHP application on this site is the M'Cheyne Bible Calendar. You're welcome to have a look at the source code. It was formerly written in Perl, but greatly benefitted from being rewritten in PHP, particularly in the speed of execution. In addition, with PHP I was able to make the code much tidier and easier to maintain.
The database backend for the M'Cheyne calendar introduced me to the object-oriented programming facilities of PHP which, although limited, are very interesting. Other applications I've developed have benefitted from being designed in an object-oriented way.
The very pages you are looking at are served by a PHP script. The script builds up the page decoration and indexes that are common to all the pages and then just includes the body text from a file. This template approach makes the pages very easy to maintain. The urls used to access the pages are rewritten by the rules in the .htaccess file to point to the PHP script that generates the pages.
I also use the PHP template technique for generating my sermon pages, where the details of the sermons are stored in a database. The information in the database is used for generating both the the sermon index page and the individual sermon pages themselves. I do not store the sermon text itself in the database, only a pointer to the file containing the text.
