Wer Module nicht wie bei OXID normalerweise üblich pflegen möchte:
search => efifactfinder/efiFactfinderSearch
Sondern lieber auf solch einen Stil steht:
search => efi\_FactFinder\_Search
der ist bei meinem Autoloader genau richtig. Ich persönlich finde, die bisherige Modulpflege verlangt leider einige Redundanzen die auf Grund der API-Sicherheit nun seit Jahren beibehalten werden. Warum macht man das so? OXID bietet updatesichere dynamische Modulketten - oder besser, einen IoC-Container für Module der Core-Klassen - nämlich bereits seit Jahren an. Manch einer hatte dieses Konzept anfänglich nicht für sinnvoll erachtet doch ich finde es toll. Ich versuche euch mit meinem Autoloader eine Möglichkeit zu bieten, den OXID-Styleguide weiter an andere berühmte Styleguides, wie dem des Zend Frameworks mit Magento, anzugleichen und so eure Projekte intern weiter zu harmonisieren.
Da die Updates für OXID 4.6 abgeschlossen sind, ist der Autoloader nun auch ein OXID Projekt-Fork auf Github. Hier könnt Ihr es downloaden, einsehen oder auch mit mir weiterentwickeln.
Ich benutze den Autoloader nun seit einigen Jahren nahezu unverändert und konnte auch andere großen Agenturen überzeugen, dass diese Modullogik einen gewissen Charme hat, doch OXID 4.6 hat mit seiner neuen Modulverwaltung einige Updates erforderlich gemacht.
Um die oben gezeigten Klassennamen, die bereits den Dateipfad wiedergeben, seit OXID 4.6.0 nutzen zu können, reicht es nicht, nur den Autoloader in der functions.php zu notieren.
<?php
// functions.php vor OXID 4.6
require\_once realpath(dirname(\_\_FILE\_\_) . '/WBL/Modules/Autoloader.php');
$oAutoloader = new WBL\_Modules\_Autoloader();
spl\_autoload\_register(array(
$oAutoloader->setAutoloaderNamespaces(array('WBL')),
'includeClass'
));
unset($oAutoloader);
?>
sondern wir müssen seit OXID 4.6 den Modullogiken aus dem Core auch mitteilen, dass Moduleinstellungen ohne Pfad vollkommen in Ordnung sind.
<?php
// functions.php seit OXID 4.6
require\_once realpath(dirname(\_\_FILE\_\_) . '/WBL/Modules/Autoloader.php');
$oAutoloader = new WBL\_Modules\_Autoloader();
spl\_autoload\_register(array(
$oAutoloader
->addCoreOverride('oxutilsobject', 'WBL\_Modules\_UtilsObject')
->setAutoloaderNamespaces(array('WBL')),
'includeClass'
));
unset($oAutoloader);
?>
Wie dieses Schnipsel zeigt, ist leider auch ein “Core Hack” enthalten. oxUtilsObject ist eine Core-Klasse die von OXID nicht über die übliche API überlagerbar ist doch mit seiner Methode _getActiveModuleChain(array) dafür sorgt, dass wirklich nur Module geladen werden, die nicht in der Config aDisabledModules zu finden sind.
Diese Core-Klasse wird im OXID-Framework so früh geladen, dass es hier noch gar keine Chance gibt, die eigentlichen Module aus der Datenbank auszulesen. Ein Modul von dieser Klasse müsste also quasi schon von Beginn an, in der Moduleinstellung zu finden sein. Um Seiteneffekte zu vermeiden, darf die entsprechende Einstellung aber auch nicht Teil der Datenbank oder dauerhaften Modulspeicherungen werden. Da oxUtilsObject ein OXID-Singleton ist, reicht es also, das Modul kurz vor der ersten Instanziierung in die Moduleinstellung aModules zu speichern, damit OXID die übliche Modullogik für das Laden der Instanz abfeuern kann, und es danach wieder zu entfernen.
Und genau dafür sorgt der Autoloader selbst. WBL_Modules_Autoloader->addCoreOverride(‘oxutilsobject’, ‘WBL_Modules_UtilsObject’) sorgt dafür, dass OXID weiß, lade bitte eine andere Klasse, wenn oxUtilsObject angefragt wird, indem WBL_Modules_Autoloader::handleCoreOverrides(string) das registrierte Modul vor dem Laden in die Config hängt, oxUtilsObject mit dem Original-Autoloader laden läßt und die Config danach wieder auf den Zustand vor dem Laden zurücksetzt.
Die andere Seite der Medaille ist oxModuleList. Diese Coreklasse hilft primär beim Handling der Module im Backend. Die Modullogik von OXID erwartet, dass ein Moduleintrag mit dem Pfad anfängt. Der WBL Autoloader erwartet aber, dass der Klassenname mit dem Pfad startet, genau diesen Unterschied gleicht WBL_Modules_ModuleList aus. Praktischerweise ist der Ordner auch die entsprechende Modul-Id.
Happy Coding,
Björn