This is an old revision of the document!
This page is not fully translated, yet. Please help completing the translation.
(remove this paragraph once the translation is finished)
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!
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.
Globale Konstanten (ebenso wie globale Variablen), benutzt innerhalb von Klassen, durchbrechen deren klare Datenkapselung und können die Wiederverwendbarkeit von Code verhindern. Siehe 'Grundlagen der Objektorientierten Programmierung'.
Globale Konstanten sind ja, wie schon seit langem bekannt, ab dieser Version deprecated, sprich unerwünscht. Siehe: Deprecated-Liste Eintrag 10 v. 12.2013
Selbstverständlich funktioniert das jetzt nicht so, dass man alle bisherigen Konstanten einfach nur Ersatzlos streicht. Das ist schlichtweg unmöglich. Zumindest im ersten Schritt stellt die Klasse 'WbAdaptor' jedoch Eigenschaften bereit, die den bisherigen Konstanten ähneln.
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!!
Liste mit neuen Bezeichnern und Beispielen des jetzigen Inhaltes.
(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:
Für alle Angaben gemeinsam gilt:
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/ |
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:
Die System-Werte sind geschützt und können nicht durch Request-Werte oder anderes überschrieben werden.