Managing Research Group Web Sites with a Database and Perl

Geoffrey Hinghing@cis.ohio-state.edu

Stephen Conleyconleys@cis.ohio-state.edu

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->E-mail->Database

Initial ideas - Web->E-mail->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.