Karen comments on the Tiny Perl Server Pages article in August’s Dr Dobb’s Journal, saying that it seems familiar as “we have implemented a system that works in an similar way to this one.”

Although on the surface this article may imply this, due to its comments on session management, MVC architechtures and database tables of pages etc (the article in the magazine has much more precursive discourse than the online version), but on closer inspection the TPSP code itself doesn’t really achieve any of this! In fact it’s just a poor imitation of PHP in the JSP/ASP mold.

FireCore (our website development) system is really at 180 degrees to this sort of system. To explain I’ll go back to 1995 when I wanted to start to add some dynamic elements to the websites I’d been building. At that time there were really only two approaches: SSI and CGI.

SSI (Server Side Includes) were ‘special’ HTML tags that I could use within my HTML to execute commands. Most commonly used with the ‘X-bit hack’, all you needed to do to change a plain HTML file to one that got pre-parsed by the server was ‘chmod +x pagename.html’.

Then to, for example, include today’s date, you would write HTML that looks something like this:

<p>Today's date is <!--#echo var="DATE_LOCAL" -->

Or to give the date this file was last modified:

<p>Last modified: <!--#flastmod file="index.html" -->

The other common use was to include the output of a different program (such as a hit counter):

<p>There have been <!--#include virtual="/cgi-bin/counter.pl"--> hits since 1st January 1995.

For simple changeable text within a web page this method was fine, and I used it quite happily for a few months. But it wasn’t enough for pages where the entire content would change – for example a search page. For that I was told I needed to learn CGI.

CGI is basically SSI inside out. Instead of your HTML containing some code that gets included, your write code and bind it in your webserver to be executed when a given URL is requested. Your code then gets executed and generates the HTML that will be emitted back to the browser.

In some ways this distinction is quite subtle, and basic ASP pages rarely differ that much from basic CGI pages. But as you start to do more advanced things the differences start to get greater, particularly as you start to deal with the problem of separating your presentation from your content. All sorts of people have attempted to describe how an MVC architecture can be implemented with a Server Page approach, but in general they all fall down as the View is driving everything rather than the Controller. With a CGI approach, you can get a better separation of concerns, as the CGI itself can act as the Controller.

Of course just as SSI has come a long way with ASP, JSP, PHP etc., CGI has also come a long way with many different approaches for each language. One of the most common approaches though, and the one that FireCore uses is mod_perl with Apache. Although many people run mod_perl almost exclusively with Apache::Registry, a simple wrapper around traditional CGI scripts, mod_perl is much more powerful than that. In FireCore’s case there are no CGI scripts at all. Each request gets handed to the FireCore::Request factory object, which examines the URI and loads the relevant Controller object which can examine the parameters passed, fetch the correct Model object(s) and pass them on to the View. The goal is that for most pages, all that is needed is the correct template file for the View to parse, but it is possible to intercept at any point in this, and do whatever you need.

Karen further asks, on this note, if all across the world companies that use Perl for building web based applications are all busy writing the same thing. Well, I don’t think this is at all a phenomenon unique to Perl (in fact I’d say there’s probably more code re-use in the Perl world than with most other languages), but I think it’s probably true. After all no-one else’s code could ever be as good/clear/specific to what we need as my code, could it? And some wheels are just meant to be triangular.

With FireCore we tried to avoid reinventing too many wheels! Really FireCore is just the initial mod_perl handler and a collection of useful generic Controller classes for database-backed web-pages (Viewer, Editor, Eraser, Uploader, Searcher etc.). The Model is handled by Class::DBI, and the View by Template::Toolkit – both well supported, actively maintained, widely used suites of modules available from CPAN.

This lets us build our sites really quickly, freeing up enough time to go reinvent some other wheels instead.