Running Weblogs with Slash

How Information Is Stored

Slash is very much tied to the database and was designed around the idea that all data will come from the database. Despite this, it tries to avoid being tied to any one database and fetching as little data as necessary. All information in Slash finds its way to the database at one point or another. Generated pages also come from the database but not always through a direct path.

Inheritance and Database Independence

All Slash libraries that access the database follow a standard method of achieving database independence. Consider Slash::DB, the core library used to gain information about the internal workings of the system. A client application gains access to the Slash::DB object’s methods by calling it:

my $user = getCurrentVirtualUser();
my $slashdb = Slash::DB->new($user);

A DBIx::Password virtual username provides the Slash::DB object with two vital pieces of information. First, the library provides a handler to the correct database. Second, it can tell the module what type of database is being used. (Only MySQL and PostgreSQL are supported. As of this writing, Oracle support is not yet finished.) This is all the information that a well-written library needs. At no point should any application that uses a database from Slash need to understand anything specific to the database. If you decide to extend Slash, keep to this rule, or you will find that porting will become an even larger, hairier gorilla.

To provide their objects with the ability ...