Managing Research Group Web Sites with a Database and Perl Geoffrey Hing Stephen Conley

The Problem - Website Management

General Website Management Problems " Dependent on a single administrator. " Managing Hypertext can be difficult. " It is often difficult to keep up with frequently changing data. " Site re-designs require almost complete rewrite of HTML.

Problems specific to research groups " Limited privileges on webserver – no root access/ability to configure webserver – unable to use CGI " Research group content uses varying types of data – Plain text/hypertext – Source code – Postscript/PDF – Powerpoint/other presentations

The Solution

Database separates data from presentation. " Makes site re-design easier " Minimizes the writing and re-writing of HTML

Software can allow for more decentralized administrations " Users update their own data " Administrator only checks and then commits changes.

Possible off-the shelf solutions (and their shortcomings) " Concurrent Version System (CVS) – Solves problem of decentralized administration – Individuals still have to code/update HTML " Zope, Slash, eGrail, Sourceforge, etc. – Requires administrator privileges to install/maintain – Don't necessarily handle specific needs of research groups, e.g. different data types easily

In-house solution seems best " Can be tailored to meet the specific needs of a research group " Can work around restricted access issues

Solution design

Initial ideas - Web-> ->Database

" Solved the problems with no CGI " Was very complicated, kludgey to implement.

Proposed solution

The Database

User interface " Web based interface " Menu driven console program " Tk GUI " Write functions for database interaction so they are independent of UI. " User updates database fields, and they are marked as uncommitted " Administrator checks uncommitted database updates and marks them as committed

Back end " Scripts write committed database entries that have been modified to static HTML files

Why scripting languages? " Fast prototyping: ideas can be tested as quickly as the code can be written. " Platform-independent: most scripting languages run on a wide variety of operating systems and hardware. No recompiling needed. " Future flexibility: changes can be made with a minimum of hassle. " No risk of anyone ever losing the source code!

Possible Languages " Perl - Larry Wall's Practical Extraction and Reporting Language. " Python - Named after a large snake or a British TV show. Object-oriented scripting language. " PHP - HTML-embedded scripting language. " Others: Tcl, Bourne shell, C shell, etc. Perl and Python offer more features than most scripting languages.

Why Perl? " We know it. " It has an excellent database interface (PerlDBI) for connecting to RDBMS like Sybase. " The philosophy behind Perl is almost the antithesis of the one behind RESOLVE/C++, so it will be interesting to see how easily the RESOLVE discipline can be applied to Perl applications development. " Did we mention that we know it?

More Reasons for Perl " PHP can be ruled out because it's designed for server-parsed web pages, and we do not have control of the server. " Text processing (which is essentially what we're doing) is what Perl was designed to do. " There's a Perl module for using Tk's wish. " Perl is the world's first postmodern programming language according to Larry Wall. We're not sure what that means but it sounds good.

Larry tells us why Perl is good: " "I lovingly reused features from many languages... I picked the feature set of Perl because I thought they were good features. I left the other ones behind because I thought they sucked." – Perl, the first postmodern computer language " "Perl appeals to the other side of your brain, whether that's associate, artistic, passionate, or merely spongy." – Programming Perl

Object Oriented Perl " Perl was not originally an object oriented language. " Object oriented features were added in Perl 5. " It will be interesting to see if and how those features will come into use for this project.