TurtolCMS Internals

Introduction

TurtolCMS is written in Python, and designed to be run under Apache with mod_python. It most likely could be adapted to run as a CGI process, and there is already a (limited) command-line tool for testing purposes.

Tcms renders pages by looking up the path_info passed in by mod_python in it's "pages" table. The path_info this 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 object of the class indicated by the database. Here is where the fun begins. If the classname listed in the database is that of an extension or plug-in, then all bets are off as to what happens next; that's up to you. In the case of the built-in types, however, we can offer a little guidance.

In any discussion about how Tcms works, however, we have to be careful to distinguish between the internal workings of the python code, the data represented by the database, and the documents (pages) eventually sent to the browser. Because these all share common words like "page" and "widget" and "template" and "layout," it may take a bit of mental agility to keep all the context straight. And of course, there's also a "context" object within Tcms to confuse you further.

Request Processing

There is a single interface point to the TurtolCMS: the Context 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 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.

The Context instantiates the appropriate page (as described above) and hands the Request off to that page via its ProcessPost and/or ProcessGet 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.Pages.HtmlPage, TurtolCMS.Pages.TemplatePage and TurtolCMS.Pages.LayoutPage. TemplatePage is an alias for HtmlPage, but the classname distinction is useful for the editor interface. Basically, a fully-formed page is represented by an HtmlPage, which has as its "parent" a TemplatePage, which has as its parent either another TemplatePage or a LayoutPage. HtmlPage and TemplatePage both hand off processing to their parent until it eventually gets to LayoutPage, which does all of the actual work involved in constructing the HTML.

Media Pages

coming...

CSS and JavaScript Pages

coming...