Programmieren ohne globale Konstanten und Variablen.

Mittelfristig ist geplant, in WebsiteBaker eine 'Registry' aufzubauen. Bis diese endgültig steht, wird die Klasse 'WbAdaptor' einen Teil deren Aufgaben übernehmen. Zu allererst stellt die Klasse Eigenschaften bereit, die mit den bisherigen Konstanten mehr oder weniger identisch sind. Parallel dazu stehen auch die alten Konstanten, für alten Code, -noch- unverändert zur Verfügung, jedoch dürfen sie nicht mehr für neuen oder überarbeiteten Code benutzt werden!

Globale Konstanten haben eine grundlegende Eigenschaft, die 'fauler' Programmierung sehr entgegen kommt: Einmal deklariert, stehen sie ohne jeglichen Zusatzaufwand an absolut jeder Stelle des Quellcodes direkt zur Verfügung. Sichtbarkeits- und Gültigkeitsbereiche spielen für sie keinerlei Rolle. Ganz 'faule' Programmierer benutzen Konstanten zweckentfremdet als Variablen, die irgendwann im Ablauf gesetzt werden und dann in nachfolgenden Funktionen ohne extra Übergabe verfügbar sind. Den scheinbaren Vorteilen stehen jedoch auch deutliche Nachteile gegenüber. Sicherheitskritische Daten gehören niemals in Konstanten abgelegt. Das schönste Negativbeispiel sind in früheren WB-Versionen die Zugangsdaten zur Datenbank, die dadurch im letzten Droplet, im letzten variablen Codestück eines Templates etc. für jederman absolut frei zugänglich waren.

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 im Prinzip entsprechen.

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 meist 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 Konstanten-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!)

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. Eine URL endet immer mit einem Slash / ohne einen Dateinamen
• 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
  

   $sPath = str_replace('\\', '/', $sPath); 

• 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
  

   $sPath = rtrim($sPath, '/').'/'; 

• Führende Slashes / werden entfernt mit
  

    $sPath = ltrim($sPath, '/');  

ALT ⇒ NEU Beispiele:

Diese Klasse ist von überall zu erreichen. Es genügt völlig, die einzig existierende, aktive Instanz der Klasse mit

 $oReg = \bin\WbAdaptor::getInstance();

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:

 echo $oReg->TemplateDir.'images/logo.png'; 

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.