Architecture for application creators #

This page is for application creators who want the map before they write code: what happens on a request, which part of the installation does what, and where an application's code belongs. The standards section explains the kernel's architecture in depth (Kernel architecture).

Contents #

1. The parts of an installation
2. A request, step by step
3. Where your code goes
4. Settings and their order
5. Command line and background work

The parts of an installation #

From 1.2 The parts of an installation:

kernel/, lib/      the kernel: modules, classes, the template engine, the database layer
autoload/          the kernel's class map (autoload/ezp_kernel.php)
extension/         extensions: your application lives here
design/            designs: templates, stylesheets, images
settings/          shipped settings; settings/siteaccess/ and settings/override/ hold yours
var/               runtime: caches, logs, storage, the SQLite database
bin/php/console    one entry point for every command
cronjobs/          the scripts runcronjobs.php runs
index.php          the front controller

A request, step by step #

1. index.php starts the web kernel (ezpKernelWeb).
2. Siteaccess: the address is matched against site.ini [SiteAccessSettings] MatchOrder; the siteaccess's settings load (Siteaccesses).
3. URL translation: a URL alias is turned into a module address (/About-us to content/view/full/58).
4. Module and view: eZModule finds the module in ModuleRepositories[] and extension module directories, checks the view's policy functions and runs the view script, which returns a $Result (Custom modules and views).
5. Templates: the view renders a template found through the design chain; the result goes into pagelayout.tpl (View results, templates and the pagelayout).
6. Caches short-cut most of this for repeat requests: the content view cache, cache blocks, the Velocity response cache.

Where your code goes #

Never edit kernel/, lib/ or another extension in place: an update replaces them. Use the registered extension points first; a kernel class override is the last resort (Extension points).

Settings and their order #

An INI value is read from settings/<file>.ini, then the extensions' siteaccess directories and settings/siteaccess/<siteaccess>/, then the active extensions' settings/, then settings/override/; the last one wins, so an active extension's settings/ wins over settings/siteaccess/<siteaccess>/. ./console exp:ini where <file>/<block>/<key> <siteaccess> shows every file that sets a value (Settings and INI files).

Command line and background work #

The same classes run outside a web request: console commands (bin/php/console), cronjob parts (runcronjobs.php), and queue workers (expqueue). Kernel scripts, parts and views are classes now (Exponential\Runnable\Command, CronjobPart, ModuleView), and your own can be too (Commands, cronjob parts and module views as classes).

Related pages #

• Exponential as an application platform
• Anatomy of an extension
• Layering and naming
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.