Das OXID eCommerce System gibt es schon lange. Lange vor der Zeit von PHP 5.3 und einer der sinnvollsten Hilfsmittel in der objektorientierten Progammierung: Namespaces. PHP Namespaces erlauben eine einfache Gruppierung von Klassen, also den Objekt-Vorlagen.
Warum sollte man hier eine Gruppierung anstreben? Nun, einfache objektorientierte System kommen alleine schnell auf 100 Klassen, und darunter gibt es garantiert solche die "Controller", "View", "Database" und so weiter heißen, weil diese Klassennamen einfach sehr typisch sind. Ein Shop-System wie OXID hat sehr viel mehr Funktionalität als ein einfaches PHP-Framework. Hinzu kommt, dass OXID durch Module erweitert werden kann. Module bringen verschiedenste Zusatzfunktionen, Themes oder Templates oder etwas ganz anderes.
Am Ende des Tages müssen die Klassen von OXID und von dessen Modulen nebeneinander friedlich koexistieren können. Namenskollisionen sind ohne Namespaces ein schnell auftretendes Problem. Daher gab es früher den Ansatz, eigene Klassen mit eine Prefix zu entschärfen. Beispiel? Hier: "oxView", oder "oxModule". Oxid empfiehlt eigene Prefixes, je nach Hersteller und Modul und macht es selbst zum Beispiel so vor:
class oePayPalDeliverySet_Main {}
Dieser Klassennamen enthält als Bestandteile ziemlich viele Informationen die eigentlich nicht zur Tätigkeitsbeschreibung der Klasse gehören, sondern eher eine thematische Gruppierung andeuten: Es geht um OXID, das Paypal Modul, und darin das DeliverySet. Mit Namespaces würde man dies so schreiben:
namespace \Oxid\Paypal; class DeliverySet {}
Das schafft Übersicht und bringt Struktur in den Code und die einzelnen Dateien. Während viele gängige, modulare Web Frameworks Namespaces als starkes Feature einsetzen (zum Beispiel das beliebte PHP Framework Symfony, oder aber auch jQuery im Bereich der Events), haben Namespaces in OXID bisher keinen Einzug gehalten. Eine Umstellung ist schwierig, da viele Module auf das bestehende OXID-Benennungs-Schema setzen.
Unser bekanntes Zoxid Framework für OXID rüstet diese Funktionalität nach. Sämtliche Komponenten sind sauber in Namespaces aufgeteilt. Wir haben dadurch enorme Effizienz-Vorteile bei der Entwicklung von Modulen und Themes und können perfekt wartbaren Code schaffen, der logischerweise dem DRY-Paradigma folgt.
Kunden, die unser Zoxid Framework oder ein responsives OXID Theme aus unserem Hause einsetzen, können auf die volle Funktionalität unseres Frameworks auch mit eigenen Modulen zugreifen und gleichzeitig die Funktionen aus OXID wie gewohnt über dessen APIs aufrufen. Damit sind endlich Namespaces in OXID angekommen.
Namespaces werden seit PHP 5.3 unterstützt und bringen entscheidendede Vorteile bei größeren, verteilten Projekten wie OXID.
* Unsere Services und Dienstleistungen richten sich ausschließlich an gewerbliche Abnehmer. Daher gelten alle Preise zzgl. der Umsatzsteuer.
© copyright 2024 by zoks.net - 1939