ExiteCMS v8 Content Tree Model

The ExiteCMS Web Application Framework utilizes what has been called the Application Content Tree. Where other web based application store their program files on disk in directories, ExiteCMS works with a database driven application structure. Every web page in the application is defined by a theme, a page template from that theme, and modules assigned to that template. The Content Tree is stored in the database in the following structure:

Functional description

The Content Tree structure is used to store definitions of websites and all website pages that are served by ExiteCMS. The ERD above shows you the entities involved.

The 'site' contains everything relating to the website itself. Which hostname and port to listen to, and which theme it uses.

A site is contains web pages. The hierarchical structure of a website is represented in 'pages', where the directory tree of a website is stored using a nested tree set algorithm (link!). For speed considerations, 'pages' uses a small fixed length record which only contain the nested tree structure itself, and no data about the web page itself.

ExiteCMS works with URI segments, not with filenames, so from a URL perspective a site tree looks like it has only directories which serve a 'default index.html file', and no other files. Optionally the administrator can add an '.html' extension, to make it look like files, but ExiteCMS ignores it. There is a one-to-one relationship between the index table 'pages' and the 'page' table, which contains the actual web page definition. This includes the page title, any description or keywords, a theme template if it differs from the default defined for the site and security information, to determine access to the page. The actual page layout is defined by the template being used for the page. The template defines named sections in which you can place one or more page elements of a certain type (link to theme!). This is stored in 'page_elements'. An element can be placed on a page only once.

The actual element definition is stored in 'elements'. These are typically created when you install a module, but can be added manually as well. An 'element' has attributes like a unique name, security information, a link to the module method that produces the output, and parameters than can be passed to the method.

The actual output of an element is product by a module method. When a module is installed, an entry in 'modules' is made, which include the name of the module, and a short description. At that time 'module_methods' is populated with all the methods the module exports, together with the type of method, a name and a description. It also defines which parameters the method supports.

Based on these parameters, you can create different elements that use the same module method, but with different parameter values. For example: a blog method could use parameters to display all entries, or a selection of entries. Two elements can then be used to display different entries, by making a selection.

So, the structure of the content tree:

• a tree starts with a site
• a site has one of more pages
• a page contains sections
• you can place zero or more elements in a section
• a module defines methods that produce output
• an element calls a module method with parameters