Magento vs. OXID, Part 1, Eigene Autoloader

Mit den Postings “Magento vs. OXID” werden wir euch jetzt öfter quälen 😉

Wie man den OXID-Modulen der WBL Konzept ansehen kann, beginnt bei uns die Modularbeit meist mit dem Autoloader, denn wir laden unsere Module mit unserem eigenen Autoloader.

 

Wie wir in dem Autoloader-Posting bereits ausführlich dargelegt haben, bietet OXID mit der ./modules/function.php eine leichte Möglichkeit globale Funktionen zu überschreiben oder auch z.B. einen eigenen Autoloader zu registrieren.

Geht es nun an das Vereinen eines OXID-Moduls mit Magento kommt uns erstmal überhaupt zu Gute, dass wir mit dem Autoloader eine Möglichkeit geschaffen haben, OXID-Module in einer Magento ähnlichen Ordner-Struktur anlegen zu können und mit wblNew() einen Wrapper für oxNew() für unsere Module anbieten.

Die gute Nachricht zuerst. Magento bringt aktuell bereits einen sehr umfangreichen Autoloader Varien_Autoloader in Kombination mit einigen Include-Paths mit.

Legt Ihr eure Modul-Dateien in den korrekten app-Ordner für Magento ab, wird Magento diese Klassen über den Namen bereits finden, wenn Ihr kein spezielles Dateisuffix nutzt. Magento geht immer von .php als Endung aus.

Der interessante Punkt ist also quasi noch, wie bekommt man wblNew() oder sogar trotzdem einen eigenen Autoloader ins System? Eine API für globale Funktionen oder ein 100%tiges IoC-Konzept wie OXID mit oxNew() gibt es noch nicht.

Vielleicht ist euch hier ein Tweet von mir zur Recherche dieses Artikels bereits aufgefallen. Auch wenn es in den Magento-Foren Tipps zum Core-Hack gibt, läßt sich auch für mich nur eine einzige Logik als Ansatz wählen.

Man “missbraucht” das Event-Observing dafür. Registriert man sich einen Observer für einen Event sehr früh im Dispatching von Magento, wie z.B. für der Event “controller_front_init_before“, kann man leicht das wblNew() oder eigene Autoloader nachimplementieren. Das Posting ”How to integrate ezComponents with magento” bei stackoverflow gibt dazu noch tiefere Insights.

Damit weicht Ihr aber leider immer noch leicht von Magento-Prinzipien ab. Magento lädt Helper und Models nicht immer über den Klassennamen, sondern meist über gruppierte und refaktorierte Namen aus der Konfiguration.

Mage::GetModel() könnt Ihr aber auch mit einem vollständigen Klassennamen füttern.

Die Möglichkeit, dass der Modul-Kunde diese Klasse überschreibt, geht damit aber nicht verloren. Denn bei den oben gezeigten Include-Pfaden steht der lokale Codepool immer noch vor dem Community-Codepool und somit könnt Ihr auch über diesen lokalen Codepool und dem Klassennamen die Modulklasse aus der Community überschreiben. wblNew() ist bei Magento als ein Wrapper für Mage::getModel().

Leider fehlt bei Mage::getModel() im Gegensatz zu OXIDs oxNew() die Möglichkeit, mehr als einen Parameter an den Objekt-Konstruktur zu übergeben. Da wir Entwickler in der Regel aber den Konstruktor möglichst dumm halten, sollte das kein Problem sein 😉

Die gezeigten Beispiele haben natürlich Ihr Für und Wider, aber ich persönlich möchte Codes so gut es geht wiederverwenden und das oben Gezeigte ist beim Autoloader nun einmal die Schnittmenge. Module aber entsprechend noch weiter an Magento und vice versa anzupassen, steht uns natürlich weiterhin frei.

Bis zum nächsten Mal

Björn

 

 

 

0.00 avg. rating (0% score) - 0 votes
0 Kommentare

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *