User Tools

Site Tools


en:dev:284:registry

This is an old revision of the document!


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.

Eine wesentliche Änderung hat sich bei der Schreibweise der Bezeichner ergeben:
Wurden die Bezeichner bisher ausschließlich in Großbuchstaben geschrieben und mehrere Einzelworte durch einen Unterstrich _ getrennt, so bestehen die neuen Bezeichner zwar weiterhin aus der selben Zeichenfolge, jedoch in 'StudlyCaps'-Schreibweise ohne Trennzeichen zwischen einzelnen Wörtern.

Beispiel: aus DEFAULT_TEMPLATE wird jetzt DefaultTemplate

Die Transformation der Bezeichner erfolgt automatisch beim Einlesen in die Klasse WbAdaptor.

Soweit so gut. Damit es nicht ganz so einfach wird, hat sich bei einem runden Dutzend ehemaliger Konstanten der Bezeichner(Schlüssel) komplett verändert und auch teilweise der Inhalt!!

Geänderte Bezeichner

Liste mit neuen Bezeichnern und Beispielen des jetzigen Inhaltes.
FIXME (Achtung: diese Liste ist nicht vollständig!)

alte Konstante neuer Schlüssel Inhalt (Beispielhaft)
{neu eingeführt} Db das aktuelle Datenbankzugriffsobjekt
{neu eingeführt} Trans das aktuelle Translation-Objekt
{neu eingeführt} App das aktuelle Applikations-/Core-Objekt
{neu eingeführt} PageId die ID der aktuellen Seite
{neu eingeführt} BlockId die ID des aktuellen Blockes
{neu eingeführt} SectionId die ID der aktuellen Section
WB_URL AppUrl http: ⁄⁄ example.com/wb/
WB_REL AppRel /wb/
WB_PATH AppPath /var/www/httpdocs/wb/
in Windows alternativ ('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/
{neu eingeführt} TemplateUrl http: ⁄⁄ example.com/wb/templates/MyTemplate/
{neu eingeführt} TemplateRel /wb/templates/MyTemplate/
{neu eingeführt} 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
{neu eingeführt} AppName WebsiteBaker
STRING_DIR_MODE DirModeString rwxrwxr-x (textuelle Darstellung, entspricht 0775 Oktal)
OCTAL_DIR_MODE DirModeOctal 509 (gespeicherter Integer, entspricht 0775 Oktal)
STRING_FILE_MODE FileModeString rw-rw-r-- (textuelle Darstellung, entspricht 0664 Oktal)
OCTAL_FILE_MODE FileModeOctal 436 (gespeicherter Integer, entspricht 0664 Oktal)

Wer die Liste aufmerksam durchschaut, wird ein paar neue Gesetzmäßigkeiten erkennen:

Die Zeichenfolge WB_ wurde zu App (hat nichts mit irgendwelchen APP-Stores zu tun!!), es ist einfach nur die ursprüngliche Abkürzung für Applikation ⇒ Anwendung ⇒ Programm.
Die Zeichenfolge ADMIN_ wurde zu Acp was AdminControlPanel bedeutet, da die Funktionen und Bezeichnungen 'Backend' und 'Admin-Tools' in einer der Folgeversionen abgeschafft bzw. ersetzt werden.

Unabhängig von den geänderten Präfixes gelten folgende Regeln für Endungen:

  • xxxUrl beinhaltet grundsätzlich eine vollwertige URL mit Protokollangabe
  • xxxPath beinhaltet einen vollwertigen Pfad ausgehend vom Wurzelverzeichnis des physikalischen Dateisystems und beginnt immer mit einem Slash / bzw. c:/ unter Windows.
  • xxxRel beinhaltet einen absoluten Pfad, ausgehend von DOCUMENT_ROOT und beginnt immer mit einem Slash /
  • xxxDir beinhaltet ein oder mehrere aufeinanderfolgende Verzeichnisnamen, und darf nicht mit einem Slash / beginnen.

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.1438929879.txt.gz · Last modified: 07.08.2015 06:44 by mrbaseman