Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

brentdax (2147)

brentdax
  (email not shown publicly)
http://www.brentdax.com/
AOL IM: Brent Dax (Add Buddy, Send Message)

Just another Perl bigot...

Journal of brentdax (2147)

Monday July 04, 2005
02:15 AM

Kontent Day 2: Expanded and explained

[ #25499 ]

Today was one of those days where I did a lot (including some restructuring of yesterday's work), but all of it was too small to really talk about or even truly recall. So instead I'll answer a question and talk about the project in general.

The goal of Kontent is to write a dynamic, extensible, versioned, database-driven CMS. Think of it as a wiki site plus a message board plus an Everything Engine site plus a Scoop or Slash news site, all in one system and possibly all coexisting. Anything that can be represented as a set of discrete documents can be represented in Kontent.

And oh, by the way, each document needs to support multiple actions and render in multiple formats. And the system has to work with multiple database engines, even ones that aren't SQL-based, and on multiple web/script interfaces, not just CGI. And it has to be easy to design new types of pages, so it needs a clear separation between different concerns. And it should be written as cleanly as possible, since one of the most painful things about the systems it replaces (MediaWiki, Everything, Slash, etc.) is that the code is so spaghettied together that it's impossible to work on.

To achieve all of this, Kontent is divided into five major components. The supervisor is the top-level component; it talks to the web server and coordinates the other four components. The store translates whatever data source is being used into simple page objects. The driver implements any special behavior a page needs that involves calculating data or retrieving additional pages from the store. The adapter translates the page, including whatever data the driver may have prepared, into a format-independent "skeleton" representing the final, formatted output. (The driver and adapter are per-page roles composed into the page object, and are collectively called the page's "class".) And finally, the renderer takes the adapter's skeleton and fleshes it out into a beautifully-rendered document in whatever format the user asked for.

Anyway, I finally got a build of Pugs on this machine with working Perl 5 interop, so tomorrow I think I'll work on a DBI store module.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.