====== Die Registry (WbAdaptor) ====== 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! ===== Überblick ===== 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: [[dev:284:deprecated|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!! ===== 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) ^ |NEW |getDatabase() |das aktuelle Datenbankzugriffsobjekt | |NEW |getTranslate() |das aktuelle Translation-Objekt | |NEW |getApplication() |das aktuelle Applikations-/Core-Objekt | |NEW |getRequester() |das aktuelle Requester Objekt | |NEW |PageId |die ID der aktuellen Seite | |NEW |BlockId |die ID des aktuellen Blockes | |NEW |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_DIRECTORY |AcpDir |admin/ | |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/ | |NEW |TemplateUrl |http: ⁄⁄ example.com/wb/templates/MyTemplate/ | |NEW |TemplateRel |/wb/templates/MyTemplate/ | |NEW |TemplatePath |/var/www/httpdocs/wb/templates/MyTemplate/ | |PAGES_DIRECTORY |PagesDir |pages/ | |MEDIA_DIRECTORY |MediaDir |media/ | |WB_VERSION |AppVersion |2.8.4 | |WB_REVISION |AppRevision |2060 | |WB_SP |AppServicePack |SP1 | |NEW |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 **A**dmin**C**ontrol**P**anel 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: * xxx**Url** beinhaltet grundsätzlich eine vollwertige URL mit Protokollangabe. Eine URL endet **immer** mit einem Slash ** / ** ohne einen Dateinamen * xxx**Path** beinhaltet einen vollwertigen Pfad ausgehend vom Wurzelverzeichnis des physikalischen Dateisystems und beginnt **immer** mit einem Slash** / ** bzw. **c:/** unter Windows. * xxx**Rel** beinhaltet einen absoluten Pfad, ausgehend von DOCUMENT_ROOT und beginnt **immer** mit einem Slash** / ** * xxx**Dir** 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: | ^ 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\\ $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.