Design pattern catalogue #

This catalogue is for developers who extend Exponential or change its kernel. It lists every abstraction the code uses, where it is, and how a new implementation is plugged in, so that new code follows the patterns that are already there instead of inventing new ones. It is generated from the source code, so it is complete and current for the code it was built from; the rules that recognize each pattern are heuristic and are explained below.

Runnable examples of most of these extension points: Examples and the cookbook.

The rules the code follows: Standards and Kernel architecture.

In numbers #

The patterns #

The areas #

One page per part of the code base: every class with its patterns, and the views, functions, operators and plugin points defined there.

What was read #

The git-tracked PHP and INI files below kernel/, lib/ and extension/ of the Exponential repository (tests and vendor/ directories left out), and these extensions:

An extension is read when it is a git repository of its own below extension/ whose origin is a se7enxweb repository, or a Composer package of se7enxweb installed there; private extensions and site settings are never read. A site that has other extensions installed gets a larger catalogue when it runs the generator.

How the catalogue is built #

Run in the installation root (no database, nothing is loaded or executed; PHP's tokenizer reads the files):

php bin/php/exppatterncatalogue.php            # report which pages would change
php bin/php/exppatterncatalogue.php --write    # write doc/eng-us/standards/patterns/
php bin/php/exppatterncatalogue.php --check    # exit 1 when the pages are out of date

The output depends only on the source: no dates, no commit ids, everything sorted, so a second run on the same code writes the same bytes. Commit the pages with the code change that changes them.

Each category has a rule (the table above and each pattern's page). A class can match several categories. The rules use the class's name, its parent classes and interfaces (followed through the whole code base), its methods (static, abstract) and the registration files of the kernel: module.php (views and policy functions), function_definition.php (fetch functions), eztemplateautoload.php (template operators and functions), cronjobs/ directories, ezpEvent calls and INI settings whose value is a class name. Names are a heuristic: a class called ...Manager is listed as a facade or service even when it is something else, and a pattern implemented without the usual names is missed. Descriptions are the first sentence of each class's doc comment.