print page  |  view normal version 

Introduction

Enano as a CMS is designed to be revolutionary - it is a boon to user interface design as well as a pioneer in the developing area of merging the wiki and CMS. But Enano's technical architecture is a carefully considered framework as well, designed around a five-component model that is designed to represent the main parts that make up a CMS.

Each of these components is represented by a global singleton with many public and private methods.

Database abstraction layer ($db)

The database abstraction layer, or DBAL, abstracts database queries. This allows Enano to interface with multiple types of database servers using a unified API. A DBAL minimizes the amount of development time required, allows easy reporting of errors, and keeps code looking clean and consistent.

The DBAL also takes care of heuristic analysis of SQL queries, one of Enano's critical security features.

Session, user management, and security ($session)

The session manager provides the back-end logic for logging in and out, validating sessions, registering users and setting passwords, and retrieving and parsing access control lists (ACLs). It is one of the bigger parts of Enano, and is easily angered if you try to use its private APIs.

URL parsing ($paths)

This is being slowly (SLOWLY!) deprecated in favor of a more organized system for handling namespaces.

$paths originally started out as the code that parsed the URL and determined which page to load and handled page metadata (such as title, protection status, etc.). The current function of $paths is to calculate which page to load based on the URL. Page metadata is now generated on a per-namespace basis in the Namespace_* classes.

There are also some miscellaneous page-related tasks that $paths handles, such as system messages and calculating the page groups a page is a member of.

HTML output and templating ($template)

This is the code that generates the HTML chrome on Enano pages as well as individual pieces and parts of pages that can be customized by theme. It can spawn parsers for blobs of text as well as files; it is preferred that you use template files, because a) they can be changed on a per-theme basis, and b) they can be compiled and then cached.

The header() and footer() methods of $template remain public, but should not be used in favor of the methods of the same names in $output.

Hooks and extension infrastructure ($plugins)

This is the API you'll want to become the most intimately familiar with, because its attachHook() method is the primary way you will add functionality to Enano. In addition to attaching and running hooks, $plugins provides an API for installing, uninstalling, upgrading, and maintaining plugins, including metadata parsing.

Other important components

The core of Enano is built around the five components above, but there are several outer pieces that tie everything together.

common.php

Take a look at index.php, cron.php, ajax.php, and the scripts under install/. All of them load one shared script: includes/common.php.

Including common is the de facto way to boot up Enano. Once you include common, all of Enano's APIs are available for you to use. Common starts up the DBAL, session management, part of $paths, and plugins, and returns with the full Enano API loaded.

Common should be the file you include from CLI scripts as well. If common detects that Enano is being started from a CLI environment, it will divert to common_cli.php to finish loading.

Common is the file you load when you're looking to use Enano from a non-plugin script. Plugins should not attempt to load common.

PageProcessor and the Namespace_* classes

This infrastructure is where Enano's actual pages are handled. PageProcessor is the frontend that handles the task of deciding what namespace to use to process a page request, and the Namespace_* classes have the back-end job of fetching the page according to how the specific namespace is supposed to work.

The abstract class Namespace_Default is used if the Namespace class for a given namespace does not exist. All Namespace classes should extend Namespace_Default.

Language string processor ($lang)

This is pretty simple - it retrieves localized strings. It has some template and filtering support.

Output wrappers ($output)

$output will be an instance of one of several classes, depending on what the current page environment or user expectation is. It is typically Output_HTML for normal page generation. The $output instance takes care of the final assembly of the page, such as placing headers all in the proper order and gzipping the page when everything is done.

Overall view of Enano's architecture

This is a broad diagram view of Enano's design that showcases Enano in three main layers: backend, content, and presentation.

The backend layer is concerned with interfacing directly with the database and dealing with the raw data associated with the site.

The content layer focuses on generating the content; this includes both the text in the page and the chrome you see - the buttons to log in or out, the sidebars, etc.

Finally, the presentation layer deals with ensuring everything is assembled in the proper order and safely sent off to the browser. Much of the presentation layer deals also with Javascript code, which is not shown in this diagram.

We put "Sessions" in both the backend and content layers because the session manager dictates many aspects of the content, and there is a lot of intermingling between the template and chrome code and the session manager, since many parts of the page chrome are based on whether the user is logged in or not and the information associated with their account.

(show page tags)
Categories: (Uncategorized)
© 2007 Contributors. All content is under the GNU Free Documentation License.
Powered by Enano | Valid XHTML 1.1 | Valid CSS | Time: 0.04s