User Tools

Site Tools


en:dev:284:registry

This is an old revision of the document!


Table of Contents

FIXME This page is not fully translated, yet. Please help completing the translation.
(remove this paragraph once the translation is finished)

The Registry (WbAdaptor)

Programming without global constants and variables.

In the medium term it is planned to build up a 'Registry' in WebsiteBaker. Until this is ready, the class 'WbAdaptor' will take over this task. First of all, the class provides properties that are more or less identical with the previous constants. At the same time, also the old constants are -still- available unchanged for old code, however they may no longer be used for new or revised Code!

Overview

Global constants show a fundamental characteristic which very much supports 'lazy' programming: Once declared, they are directly available at absolutely any location of the source code requiring no additional expense. Visibility and scope don't play any role for them. Absolutely 'lazy' programmers abuse constants as variables that, eventually set in sequence, and then are available at no extra transfer in the following functions. The apparent advantages, however, also face significant disadvantages. Security-critical data are never stored in constants. The best negative example in previous WB versions are the credentials for access to the database, which were available in each droplet, each piece of dynamic code of a template etc., absolutely freely accessible for everyone.

Global constants (as well as global variables), used within classes, break up their clear encapsulation and can prevent the reusability of the code. See 'Basics of object-oriented programming'.

Global constants are, as has long been stated, from this version on deprecated, that is undesirable. See: Deprecated-List Entry 10 from 12.2013.

Of course, discarding all previous constants without any replacement is clearly not a feasible approach. That's simply impossible. At least in the first step, the class 'WbAdaptor' makes properties available that are similar to the previous constants.

A significant change has arisen about the spelling of the identifier:
The identifiers have been written entirely in capital letters and separated several individual words with an underscore _, the new identifiers however still consist of the same sub strings, but now they are written in 'StudlyCaps' notation without delimiters between words.

Example: DEFAULT_TEMPLATE becomes DefaultTemplate now

The transformation of the identifier is performed automatically when reading in the class WbAdaptor.

So far so good. To make it not too simple, for about a dozen former constants the identifier (key) and also partially the content has completely changed!!

Changed identifiers

List of new identifiers and examples of the current contents.
FIXME (note: this list is not complete!)

old constant new key content (example)
{introduced} Db the current object for accessing the database
{introduced} Trans the current translation object
{introduced} App the current application/core object
{introduced} PageId the ID of the current page
{introduced} BlockId the ID of the current block
{introduced} SectionId the ID of the current section
WB_URL AppUrl http: ⁄⁄ example.com/wb/
WB_REL AppRel /wb/
WB_PATH AppPath /var/www/httpdocs/wb/
alternatively, in Windows ('c:/var/www/httpdocs/wb/')
ADMIN_URL AcpUrl http: ⁄⁄ example.com/wb/admin/
ADMIN_REL AcpRel /wb/admin/
ADMIN_PATH AcpPath /var/www/httpdocs/wb/admin/
TMP_PATH TempPath /var/www/httpdocs/wb/temp/
TEMPLATE Template MyTemplate
TEMPLATE_DIR TemplateDir templates/MyTemplate/
{introduced} TemplateUrl http: ⁄⁄ example.com/wb/templates/MyTemplate/
{introduced} TemplateRel /wb/templates/MyTemplate/
{introduced} TemplatePath /var/www/httpdocs/wb/templates/MyTemplate/
ADMIN_DIRECTORY AcpDir admin/
PAGES_DIRECTORY PagesDir pages/
MEDIA_DIRECTORY MediaDir media/
WB_VERSION AppVersion 2.8.4
WB_REVISION AppRevision 2060
WB_SP AppServicePack SP1
{introduced} AppName WebsiteBaker
STRING_DIR_MODE DirModeString rwxrwxr-x (textual representation, corresponds to 0775 octal)
OCTAL_DIR_MODE DirModeOctal 509 (stored integer, corresponds to 0775 written in octal)
STRING_FILE_MODE FileModeString rw-rw-r-- (textual representation, corresponds to 0664 octal)
OCTAL_FILE_MODE FileModeOctal 436 (stored integer, corresponds to 0664 written in octal)

Who looks attentively at the list, will recognize a few new laws:

The string WB_ became App (has nothing to do with any of these App Stores !!), it's just the original abbreviation for application ⇒ program.
The string ADMIN_ became Acp which is the abbreviation for Admin Control Panel, because the functions and names 'backend' and 'admin tools' will be abolished or replaced in one of the subsequent versions.

Regardless of the changed prefixes, the following rules apply for extensions:

  • xxxUrl basically includes a full URL with protocol specification
  • xxxPath includes a full path starting from the root directory of the physical file system and always begins with a slash and c:/ for Windows. * xxxRel includes an absolute path, starting from DOCUMENT_ROOT and always begins with a slash
  • xxxDir contains one or more successive directory names, and must not start with a slash . Für alle Angaben gemeinsam gilt: * Als PATH_SEPERATOR ist ausschließlich der Slash / zugelassen. Anpassungen können problemlos erfolgen mit
    <php> $sPath = str_replace('\\', '/', $sPath); </php> * Ist das letzte Element einer URL-,Rel-, Path-, oder Dir-Angabe ein Verzeichnis, so
    muss die Angabe mit einem Slash / enden.
    * Um sicher zu stellen, dass ein Verzeichnis mit einem einzelnen Slash
    / abgeschlossen wird genügt die kurze Sequenz
    <php> $sPath = rtrim($sPath, '/').'/'; </php> * Führende Slashes
    / werden entfernt mit
    <php> $sPath = ltrim($sPath, '/'); </php> ALT ⇒ NEU Beispiele: | ^ Schlüssel ^ Wert ^ ^alt | WB_URL | http: ⁄⁄ example.com/wb | ^neu | AppUrl | http: ⁄⁄ example.com/wb/ | ^alt | ADMIN_REL | /wb/admin | ^neu | AcpRel | /wb/admin/ | ^alt | PAGES_DIRECTORY | /pages | ^neu | PagesDir | pages/ | ^alt | TEMPLATE_DIR | http: ⁄⁄ example.com/wb/templates/MyTemplate | ^neu | TemplateDir | templates/MyTemplate/ | ===== Anwendung von WbAdaptor ===== Diese Klasse ist von überall zu erreichen. Es genügt völlig, die einzig existierende, aktive Instanz der Klasse mit
    <php> $oReg = WbAdaptor::getInstance(); </php> in den aktuellen Sichtbarkeitsbereich zu importieren. Noch besser ist jedoch die Nutzung von Dependency-Injection, also die Übergabe der Instanz von außen an die Funktion oder Klasse. :!: Es wird dringend empfohlen, den Bezeichner $oReg für die Instanz des WbAdaptor-Objektes zu verwenden um eine leichtere und über alle Programmteile durchgängige Lesbarkeit zu erreichen. Auch der Abruf der einzelnen Werte ist recht unproblematisch:
    <php> echo $oReg→TemplateDir.'images/logo.png'; </php>
    Ausgabe: templates/myTemplate/images/logo.png Was nach außen nicht sichtbar ist, ist der Umstand dass alle abrufbaren Werte in zwei Basis-Gruppen abgelegt sind: * System ⇒ das sind alle Werte, die bei unveränderten Grundeinstellungen bei jedem Scriptaufruf
    immer gleich sind. * Request ⇒ alle anderen Werte, die je nach Seite, Benutzer, Requestmodus oder sonstigen Kriterien unterschiedliche Werte haben können. Die System-Werte sind geschützt und können nicht** durch Request-Werte oder anderes überschrieben werden.
en/dev/284/registry.1439409580.txt.gz · Last modified: 12.08.2015 19:59 by mrbaseman