Underneath, there are 3 tables


The database

There are three basic tables in the MySQL database. One contains content, and referenced by mcid. The second contains any binary content (images, PDFs) and is referenced by an miid The final contains sections referenced by msid, which are a mechanism for organising and classifying content and images.

Around these three tables live some utility tables that contain basic logging information (a simple page count per fragment) and caching. Each page, when first rendered, is cached to a separate table. This enables faster response on the second and subsequent hits. To ensure that only current pages are cached, there is a simple cachetree implemented such that when a change or deletion to a record is made, the cache is pruned. (the page cache is presently disabled)

These sections provide the underlying hierachical structure of the site. This structure is tightly bound to the navigation through the site. As this is in the database, it is very easy to change the underlying navigation structure without changing how individual pieces of content are referenced. Usually, the structure is defined as a folder hierachy on the server. As soon as you start moving the folders around, the references from one piece of content to another breaks – forcing a mass update of the site. External search engines that may have the links stored in their database get 404 style errors. In the mungenetengine, each content, image and section is referenced individually without relationship to its place in the navigation structure.

Each fragment of content or image belongs to a section. These sections are the hierarchy behind the site – so each section can belong to another section, and a particular section can have multiple child-sections. A section can only have one parent. As you move to another section or page within another section, the mungenetengine (renamed to mne.php) can generate a navigation fragment; which is a template driven hierarchy containing links to the parent section, sibling content pages or sections, and any children.

In fact, each content entry is just a fragment of html. A whole page may actually comprise of other referenced contents elements, each inserted into the final html that you seen in the browser. The process of building one page from another is a process called templating. Its not as simple as one page referencing another; this process is recursive – one page refers to another until the final page is built. The concept here is to only enter data only once into the database. Each content can insert other fragments (or images) into the html output.

There are different types of content fragments. For instance, one is an external link – these contents are resolved, and wrapped into an HREF style link.

Images are in fact binary objects. They are wrapped into the final html – except they refer back to the mungenetengine – which grabs the images out of the database and serves them up. html fragments that are generated automatically add the width/height, alts and hrefs normally associated with images – if they are in the database. PDFs and other non-image content can be linked to so the user can download them, or embedded into the HTML fragment.

SWF and SVG can also be stored in the database. When rendering out these elements, the engine generates object embed tags. The width and height are not read from either format as yet. Whilst it is possible to read the ‘twips’ from a SWF, it seems overly complex to do – just yet

The engine can also generate what are known as breadcrumbs (next and previous links) — this is easy as the structure and relationship between objects are known and map to the navigation

PHP, the server side scripting language, munges the data together from the MySQL database and serves it up. As at early February 2003 this code is about 1870 lines long. I am testing this on WindowsXP and transferring it here to a Linux box for production. I really only have a choice of three server side scripting systems (PHP, Perl or Python). Learning PHP has been a great experience.

The next stage is to transfer the experience here into using a better language that has more object orientation. I have chosen Python as the langauge to accomplish this task. How long this takes, only time will tell!