Hallo an euch alle,
ich bin nun mit meinem Modul fast fertig (sind nur noch Kleinigkeiten) und habe prompt einen Verbesserungsvorschlag aus einer Technik die ich bei Magento und Shopware kennen gelernt habe.
Es geht um das eingreifen in bestehende Core Funktionalitäten. Mir ist schmerzlich aufgefallen das, wenn man z.B. eine Model oder Controller Klasse in seiner Funktionalität erweitern und manipulieren will man gezwungen ist die bestehenden Klassen zu erben und dann dort Methoden etc. zu überschreiben.
Das finde ich persönlich nicht wirklich gut und gelungen umgesetzt. Wie kann man dies deutlich verbessern? Nun Magento und Shopware machen dies auf sehr elegante Art und Weise vor.
Kleine Gegenüberstellung wie die Systeme das machen.
[B]Magento:[/B]
Magento stellt ein Event Obersver Pattern da zur Verfügung. Das bedeutet man kann da in seiner XML Datei (config.xml) Events registrieren.
Sieht kurz geschrieben so aus.
<events>
<sales_quote_save_before>
<observers>
<mycompany_coupon_sales_observer>
<class>mycompany_coupon/sales_observer</class>
<method>calculateMycompanyPrice</method>
</mycompany_coupon_sales_observer>
</observers>
</sales_quote_save_before>
</events>
Alles was in Events steht wird registriert im Event Observer von Magento.
Der Node <sales_quote_save_before> legt das auszuführende Event fest.
Der Node besagt das es sich um einen Oberserver handelt.
Der Node <mycompany_coupon_sales_observer> gibt Pfad und Klassenname des Obersvers aus dem eigenen Modul an.
Der Node dient im Magento dazu ein Obersver Objekt zu instanzieren vor dem / steht der Pfad zum Modul und dahinter interne Pfad zur eigentlichen Observer Klasse, hinter dem letzten _ steht immer der Klassenname.
Der Node legt die Methode fest die Obersver Code ausführen soll.
[B]Shopware:[/B]
Shopware legt für jedes Modul eine Bootstrap fest und in dieser gibt es dann eine Methode isntall(), diese wird nur ausgeführt wenn im Backend das Modul installiert wird. In dieser kann man dann Events und Hooks definieren. Über die Methode subscribeEvent(); werden dann bei der Modulinstallation Events und Hooks in die Datenbank gespeichert. Shopware nutzt bzw. baut dabei auf den Event Manager von Symfony auf.
So sieht das in der Boostrap aus.
$event = $this->createEvent(
'Enlight_Controller_Action_PostDispatch_Frontend_Checkout',
'onCheckoutPostDispatch');
$this->subscribeEvent($event);
Im ersten Teil der createEvent() Methode wird gesagt das ein Event im PostDispatch des Checkout Frontend Controllers ausgeführt werden soll.
Der zweite Teil besagt die Event Mothode. Und diese sieht dann im Code folgendermaßen aus.
public function onCheckoutPostDispatch(Enlight_Event_EventArgs $args)
{
}
Über den Parameter $args welcher ein Objekt von Eventargumenten beinhaltet hat man auf die verschiedensten Funktionalitäten udn Daten Zugriff die zu diesem Zeitpunkt existieren und verfügbar sind.
Das Post und Pre Dispatch kommt daher, weil auch Shopware wie Magento auf dem Zend Framework aufbauen.
Das ist aber nebensache und dient nur zur Anschauung.
Zusätzlich bietet Shopware aber noch die Funktionalität von sogenannten Hooks, dass heißt man kann zu einem ganz bestimmten Zeitpunkt in einer Methode seinen Code aus seiner Event Hook Methode ausführen lassen.
Bei beiden liegt der Vorteil gegenüber Oxid klar auf der Hand. Ich kann eigene Modulfunktionalität in die Core Klassen injecten ohne auch nur ein bisschen zu erben und bestehende Methoden verändern zu müssen. Bei Magento muss das nur ganz selten und bei Shopware gar nicht (ist mir zumindest nicht aufgefallen).
Nun ich finde den Oxidshop gerade in seiner Geschwindigkeit überragend und wenn man nun noch ein solches Eventmangement einbringen würde für die Modulentwicklung waäre Oxid meiner Meinung nach der Renner schlecht hin.
Ich hoffe das hier eine geute Diskussion herauskommt in der man neue Erkenntnisse gewinnnen kann.
Ich grüße euch und die Diskussion ist eröffnet.
Gruß Daniel
