This site is currently implemented using MODX, and not very well on my end as I wanted something fast. It is also residing on a basic Linode running Debian Linux. I was always intending on creating a new site, but was most likely going to use an existing CMS, like Drupal.
I'm not a fan of PHP and have starting wanting to redevelop this site using Ada, Linode lets me rexecute binaries directly as it is a virtual system. I could use the Common Gateway Interface, but this is old technology and every invocation of an URL would mean that an application will have to be spawned from the web server, this is rather slow. Enhancements to CGI are Simple Common Gateway Interface (SCGI) and FastCGI; the former is simple to implement (hence the name), the other is actually quite difficult. I had previously implemented code to handle the SCGI protocol for Jesse Lang's Solid framework, so I'll use this.
I'll also require a Unicode library, so I'll utilise the League library in Vadim Godunko's Matreshka framework. This does have a FastCGI implementation, but I won't be using that.
Also required is template parsing, so that the document style can be replaced easily. There is a template parser library in the AWS project I can use for this.
The design of this CMS is fulfill the following requirements.
First we need to think about how this CMS is going to be structured at a high-level, the following diagram shows this using the client-server model.
The CMS runs as a daemon process in the background on the operating system, the HTTPD (the web server) will be configured to send certain requests over sockets to the CMS server, the CMS will then send a response which in turn gets passed back to the client that requested it.
You'll notice in the diagram that there is an External box. This basically means that there could be other servers that the CMS daemon needs to access.
The next diagram shows how the CMS fits in with the operating system. The CMS communicates with the web server via SCGI, it also interfaces to a database server and the filesystem. Very few OS specifics will be required:
I have chosen PostgreSQL as the Database for storage of the various content within the CMS. I have heard very good things about the quality of this software from other Ada developers. There exists a number of bindings to libpq, I shall try the one in Matreshka as it also provides a common abstraction over other databases.
The following diagram shows the general abstractions that will be included in the CMS.
Documents are what the CMS is managing. Documents can be extended to create new types of documents, for example a site could have a blog document, an article document, a product document.
Each document has a number of fields that the user can complete when entering the content:
But the administrator can add new fields to the document type to give it more structure. For example, a site for a newspaper could add a photo field to a story document which could be shown at the top of the page and have it float to the right so the text flows around it.
As stated in the key concepts from the beginning of this article, each document has revision information. The database will essentially store a new version as new revision of the document, unless explicitly set by the user. It should be possible to roll back to a previous revision, thus deleting any subsequent revisions.
As mentioned in the previous section, Fields provide a mechanism for adding fields to the input forms on the documents. These fields can be anything and will provide extra features that an administrator wants to add to a site.
API's are added to the system and can be used by other modules to build extra features or content. These API's can provide admin interfaces if one is required.
These are the human's who use the site built with the CMS. Usernames and passwords, profile information can be built up separately.
Roles are given to specific users, such as Administrator, Editor, Writer, etc.
Permissions define what a user's role can do within the CMS, e.g. deleting content.
Modules provide a mechanism to extend the CMS with new Documents, Fields or API's to enhance the CMS. An example could be an online shopping system.
The cache is where pages are stored after they've been taken from the database, parsed, tuck together with the other template fragments and sent back to the client.
N.B: I have just had a thought about this, say you have advertising on a page, this could end up getting stuck with the same ad on every page request.
The database is where the content is stored.
Skip to Part 2 of this project.
If you have any comments or any ideas that I've missed out, please use the form below.