====== Allgemeine Anpassung für WebsiteBaker ====== Da WebsiteBaker schon vor Erscheinen der PHP-FIG Standards existierte sind ein paar wenige Anpassungen der Standards erforderlich, die nachfolgend beschrieben werden. Weitere Anpassungen sind in den Kapiteln zu den einzelnen WB-Versionen / Versionsgruppen enthalten und zwingend zu beachten!
{{:warning.png?nolink&32 |Warnung}} **Achtung:** Für allen neuen Code gilt auch bei Websitebaker ab sofort die Grundregel der **E**lektronischen-**D**aten**V**erarbeitung, die seit der Erfindung des Computers Gültigkeit hat und bisher bei WB mit regelrecht penetranter Konsequenz missachtet wurde: * **E**ingabe » **V**erarbeitung » **A**usgabe Diese 3 Bereiche müssen strikt getrennt werden und immer in der exakten Reihenfolge auftreten. Neue Module, die sich nicht an diese elementare Regel halten, werden in Zukunft nicht mehr in das Repository aufgenommen, beziehungsweise werden sie als '//**nicht kompatibel**//' gekennzeichnet.
===== PHP Dateiformatierung ===== ==== Allgemein ==== Für Dateien mit der Endung *.php, welche nur PHP Code beinhalten oder mit PHP Code enden, ist der schließende Tag **?>** nicht zugelassen. Er wird weder vom Webserver noch von PHP benötigt und das Weglassen verhindert, dass versehentlich Leerzeilen in die Antwort eingefügt und dadurch eventuell vorzeitig Header gesendet werden.\\ Beginnt eine Datei mit PHP Code, so ist zwingend das öffnende **{{:info.png?nolink&32 |Hinweis}} **Hinweis:** Die strikte Einhaltung dieser Konventionen ist zwingend erforderlich, damit es bei verschiedenen Modulen keine Namensgleichheiten von Klassen und Funktionen/Methoden geben kann. Der Core ist dadurch in der Lage, die Position der Klassendateien anhand der Klassennamen eindeutig zu bestimmen, um sie durch den auf WB optimierten Autoloader nachzuladen. Eine explizite Einbindung der Klassendateien per include() oder require() wird dadurch überflüssig. WebsiteBaker ab v2.8.4 erfordert PHP 5.4.x als Mindestvoraussetzung. Für eine Übergangszeit sind noch 2 verschiedene Namenskonventionen für Klassen zulässig. Das erklärte Ziel ist jedoch die durchgängige Umstellung auf Namespaces um deren Vorteile zu nutzen und auch den Benennungsaufwand bei Klassen deutlich reduzieren zu können. ==== Klassen ==== Klassennamen müssen in **StudlyCaps** (auch //**UpperCamelCase**// genannt) deklariert werden und müssen folgender RegEx-Regel entsprechen: '/[A-Z][a-zA-Z0-9]+/'. Nummern sind in Klassennamen gestattet, sollten jedoch auf das Notwendigste beschränkt werden und keine Verwechslungsgefahr mit Buchstaben bergen. Besteht der Klassenname aus mehr als einem Wort, so ist der jeweils erste Buchstabe eines Wortes groß zu schreiben. Mehrere aufeinanderfolgende Großbuchstaben sind nicht erlaubt. Beispiel anhand eines Namens: ^Bezeichner ^ Status | |smtp_mailer | [color=red]falsch[/color] | |Smtp_Mailer | [color=red]falsch[/color] | |SMTPmailer | [color=red]falsch[/color] | |SmtpMailer | [color=green]richtig[/color] | ==== Abstrakte Klassen und Interfaces ==== Generell folgen abstrakte Klassen und Interfaces der gleichen Konvention wie Klassen, mit einer zusätzlichen Regel: Die Namen von abstrakten Klassen und Interfaces sollten mit dem Term "**Abstract**" bzw. "**Interface**" enden, und dem Term darf kein Unterstrich vorangestellt sein. Als Beispiel wird //**Plugin_Abstract**// als ungültig angenommen, aber **PluginAbstract** oder **m_MyModul_PluginAbstract** wären gültige Namen. ==== Emulierte Namespaces ====
Emulierte Namespaces sind nach der 2.10.x deprecated. Der Autoloader ignoriert sie dann vollständig!
In diesem Modus ist in Klassennamen zusätzlich der Unterstrich '_' als Sonder-/Funktionszeichen gestattet. Er dient jedoch ausschließlich als Pfadseperator. Klassennamen bestehen hier nicht allein aus dem bis jetzt definierten Namen, sondern müssen zusätzlich noch genau definierte Präfixes enthalten. Nur dann ist es möglich, aus dem Klassennamen den exakten Dateinamen zu ermitteln, so dass die passende Datei bei einem Zugriff auf eine Klasse automatisch geladen(included) werden kann. Die Klassenbibliotheken von WebsiteBaker sind in mehrere Gruppen aufgeteilt:\\ **Klassen des Kerns**: sind im Verzeichnis **''wb/framework/''** oder einem seiner Unterverzeichnisse zu finden. Hierfür ist kein Prefix erforderlich.\\ **Klassen der Module**: Klassen der Module im jeweiligen Modulverzeichnis **''wb/modules/%modul_name%/''** oder einem seiner Unterverzeichnisse. Der Bezeichner muss zwingend den Prefix '**m_**' erhalten. **Beispiel:** m_MyModule_PluginInterface \\ **Klassen des ACP**: (AdminControlPanel => ehem. Backend) sind im Verzeichnis **''wb/admin/''** oder einem seiner Unterverzeichnisse zu finden. Der KlassenBezeichner muss zwingend den Prefix '**a_**' erhalten. **Beispiel:** a_Pages_PageTree\\ **Klassen der third-party libraries**: die im Verzeichniss **''wb/include/''** sowie seinen Unterverzeichnissen liegen, werden vom Autoloader nicht automatisch erfasst. Jede Library hat jedoch die Möglichkeit, eine eigene Registrierung im SPL-Autoloaderstack vorzunehmen. Mehr dazu in der Beschreibung des Autoloaders der jeweiligen WB-Version. ==== Dateinamen ==== Soweit die vorgenannten Regeln für Klassennamen eingehalten wurden, ergeben sich die Dateinamen eindeutig aus den Klassennamen. Die Klasse **m_MyModul_PluginAbstract** findet sich demnach in der Datei **''wb/modules/MyModul/PluginAbstract.php''**.\\ Für alle anderen Dateien sind nur alphanummerische Zeichen und der Bindestrich (**-**) gestattet. Leerzeichen sind völlig verboten.\\ Jede Datei, die ausführbaren PHP Code enthält sollte mit der Endung **.php** enden und in UpperCamelCase-Schreibweise ausgeführt sein. ==== Verzeichnise ==== Zur Benennung von Verzeichnissen gelten die selben Grundlagen wie für Dateien. Es sind nur alphanummerische Zeichen sowie nur wenige Sonderzeichen des Standard 7-Bit-ASCII Bereiches <128 (**[color=blue] ! # - . @ ~ [/color]**) zulässig. Wie bei Dateinamen, sind Leerzeichen und der Unterstrich grundsätzlich verboten. ==== Funktionen und Methoden ==== Funktions- und Methodennamen dürfen nur Alphanummerische Zeichen enthalten. Unterstriche sind nicht gestattet. Nummern sind in Funktionsnamen gestattet aber in den meisten Fällen nicht empfohlen. Wortreichtum wird generell befürwortet. Funktionsnamen sollten so wortreich wie möglich sein um deren Zweck und Verhalten möglichst genau zu erklären. Funktionen oder Methoden sollen möglichst immer in //**lowerCamelCase**// (oder einfach //**camelCase**//) geschrieben werden. Das bedeutet, mit einem klein geschriebenen Verb wie //get//, //set//, //add//, //delete//, //load//, //save//, //execute// etc. beginnen, das dann von einem Substantiv in StudlyCaps gefolgt werden kann, welches das zu bearbeitende Objekt beschreibt. Beispiel: $oMyObject->saveItemList(); oder reloadAllModules(); :!: **Achtung:** Es dürfen niemals doppelte Unterstriche als Prefix für Methoden-, Funktions- oder Variablennamen verwendet werden. Es besteht hier die Gefahr, dass es zu Überschneidungen mit aktuellen oder zukünftigen, PHP-eigenen Magic-Functions etc. kommt. ===== Adressierung von Dateien und Verzeichnissen =====