TurtolCMS Overview

Introduction

TurtolCMS is written in  Python, and designed to be run under  Apache with either  mod_wsgi or  mod_python. It should be trivial to adapt it to run as a CGI process, and there is a (limited) command-line tool for testing purposes. At some point, we'll also build a daemon out of the thing (Django/Rails?-style) so it can run in a wider range of situations.

Tcms renders pages by looking up the requested URI in it's "assets" table. The request URI is the portion of the URL AFTER the base location of Tcms, and from now on, we'll refer to this as the Uri (as this is how it's treated within Tcms). So, if Tcms is configured to service the /cms location under apache (see TurtolCMS Installation), and the browser was directed to /cms/news/yesterday, then Tcms would try to find a page named /news/yesterday.

In some cases, the page name will match the Uri exactly; however, if no such exact match is found, Tcms will look for the closest matching "default handler" page in the database. "Closeness" in this case means the page name must be a leading (starting at the front) substring of the Uri, and the longest such matching substring is the closest. A page is marked as a "default handler" if it is intended to handle pages "under it." Any page can be a default handler, and they don't have to do anything with the Uri, though clearly they are more useful if they do.

Once the appropriate page is found in the database, Tcms creates an asset object of the type(s) indicated by the database. Here is where the fun begins. The rendering of the page is handled by the retrieved "asset" per the rules for the "type(s)" of the "asset."

Assets and Types

Everything in the TurtolCMS is either an Asset or an AssetType.

Assets are essentially data which can be serialized into and out of a database, by way of the StorageLayer. Assets are pickled for direct storage as blobs in the underlying database, but certain "fields" in each asset may also be written to a database field (tied back to the asset by join relationships) for fast searching, aggregating, etc. Each Asset has one or more AssetType's which define both it's structure (metadata) and how it's data is to be processed.

Request Processing

There two objects which define request processing within the TurtolCMS: the Context? object and the Request? object. The TurtolCMS itself is agnostic about whatever mechanism originates requests and delivers the corresponding responses. This is the pervue of an EntryPoint. Currently, we have EntryPoints for WSGI (WsgiEntryPoint), mod_python under Apache (ApacheEntryPoint) and the command line (TcmsEntryPoint).

The EntryPoint constructs a Request object and a Context, and then calls the Context's ProcessRequest function, passing the Request along. Each EntryPoint is responsible for abstracting away the particulars of the platform it runs on, providing the Context a Request which follows a few rules the TurtolCMS core can count on.

The Context instantiates the appropriate page (as described above) and hands the Request off to that page via its Head, Get and/or Post functions, as appropriate. Different page types implement these functions differently, of course. These differences are detailed below, at least for the core types.

HTML Pages

HTML Pages are handled by a combination of classes: TurtolCMS.Types.HtmlPage, TurtolCMS.Types.HtmlTemplate? and TurtolCMS.Types.HtmlLayout. HtmlTemplate? is optional, but very useful. Basically, a fully-formed page is represented by an HtmlPage, which has as its "parent" an HtmlTemplate or an HtmlLayout. An HtmlTemplate? can have as its parent either another HtmlTemplate? or an HtmlLayout.

Media Pages

coming...

CSS and JavaScript Pages

coming...