bezahlt von Shopware: Eigene Events
Es war ein kalter und nasser November morgen. Ich saß zu der Zeit in einem ehemaligen Fabrikgebäude im tiefsten Osten Deutschlands mehrere Fahrtminuten hinter Lübeck.
Meine Aufgabe sollte es da sein ein Konzept für das Beschaffungsmodul eines ERP-Systems zu konzeptionieren. Ich stand gerade vor dem Problem, dass z.B. bei Wareneingängen, die über das Modul verbucht werden sollten, auch das Lager-Modul und das Inventur-Modul diesen Eingang verarbeiten mussten. Ich überlegte und entschied mich am Ende für ein auf MDB basierten Event-Model. Wenn etwas passierte sollte ein Event/eine Message los laufen und andere Module sollten, dieses bei Interesse nehmen, zur Kenntnis nehmen oder auch Daten anpassen können. Man war felxibel, hatte keine Abhängigkeiten und alles war erweiterbar und austauschbar. Ich war schon halb dabei was konkretes zu entwickeln... wie man sich sicher jetzt schon denken kann, kam es nie dazu. EJBs wurden direkt aufgerufen mit allen Problemen, die ich mit den Events umgehen wollte.
Ob es nun Fire-And-Forget, synchron oder asynchron, MDB-basiert oder was auch immer gewesen wäre, es wäre besser gewesen als alle benötigten fremden Services per Hand direkt aufzurufen und denen die Daten in deren Formaten aufbereitet zu übergeben. Jede Änderung an den fremden Services, die es zuhauf gab, konnte wieder alles kaputt machen und das passierte natürlich häufig, besonders weil Service-Interfaces beliebig geändert wurden und nie stabile Schnittstellen zwischen den Modulen waren.
Es war ein Fehler es nicht so zu machen, deswegen liebe ich alles was genau so arbeitet. Jetzt habe ich auch angefangen bei einigen meiner Shopware-Plugins Events einzubauen, so dass diese auch teilweise erweitert werden können. Das Preis-Warnung-Plugin ist das erste, das Events erhalten wird. Bei Shopware ist es an sich sehr einfach mit Events zu arbeiten. Als Beispiel nehmen wir uns einen einfachen Service.
namespace HPrEventTest\Components;
class EventService{
/** @var \Enlight_Event_EventManager */
private $eventManager;
public function __construct(\Enlight_Event_EventManager $eventManager = null){
$this->eventManager = $eventManager;
}
public function fireExample(){
$val = 0;
$result = $this->eventManager->filter('HPrEventTest_example', $val, ['subject' => $this]);
return $result;
}
}
Wir müssen nur noch den Event-Manager per Injection zum Service hinzufügen.
<?xml version="1.0" encoding="utf-8"?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="hpr_event_service" class="HPrEventTest\Components\EventService">
<tag name="service" />
<argument type="service" id="events" />
</service>
</services>
</container>
Wie man auf Events reagiert, weiß eigentlich jeder, der schon mal ein Shopware-Plugin geschrieben. Allein der Klassiker zum hinzufügen von Template-Dirs erklärt schon fast alles.
namespace HPrEventTest;
use Shopware\Components\Plugin;
class HPrEventTest extends Plugin{
public static function getSubscribedEvents(){
return [
'HPrEventTest_example' => 'processEvent',
];
}
public function processEvent(\Enlight_Event_EventArgs $args){
$args->setReturn($args->getReturn() + 1);
}
}
Wir feuern also ein Event mit 0, das wird in unseren Plugin verarbeitet und 0 wird zu 1 und diese 1 wird von der ursprünglichen Service-Methode auch dann wieder zurück gegeben.
Es gibt natürlich noch ein paar mehr Event-Strategien als filter(), aber an sich sind alle sehr ähnlich. Nicht bei jedem wird der Return-Wert verwendet.
Das Subject, das wir hier verwenden, eignet sich super dafür Controller und Services zu übergeben, die das Event ausgelöst haben.
Meine Aufgabe sollte es da sein ein Konzept für das Beschaffungsmodul eines ERP-Systems zu konzeptionieren. Ich stand gerade vor dem Problem, dass z.B. bei Wareneingängen, die über das Modul verbucht werden sollten, auch das Lager-Modul und das Inventur-Modul diesen Eingang verarbeiten mussten. Ich überlegte und entschied mich am Ende für ein auf MDB basierten Event-Model. Wenn etwas passierte sollte ein Event/eine Message los laufen und andere Module sollten, dieses bei Interesse nehmen, zur Kenntnis nehmen oder auch Daten anpassen können. Man war felxibel, hatte keine Abhängigkeiten und alles war erweiterbar und austauschbar. Ich war schon halb dabei was konkretes zu entwickeln... wie man sich sicher jetzt schon denken kann, kam es nie dazu. EJBs wurden direkt aufgerufen mit allen Problemen, die ich mit den Events umgehen wollte.
Ob es nun Fire-And-Forget, synchron oder asynchron, MDB-basiert oder was auch immer gewesen wäre, es wäre besser gewesen als alle benötigten fremden Services per Hand direkt aufzurufen und denen die Daten in deren Formaten aufbereitet zu übergeben. Jede Änderung an den fremden Services, die es zuhauf gab, konnte wieder alles kaputt machen und das passierte natürlich häufig, besonders weil Service-Interfaces beliebig geändert wurden und nie stabile Schnittstellen zwischen den Modulen waren.
Es war ein Fehler es nicht so zu machen, deswegen liebe ich alles was genau so arbeitet. Jetzt habe ich auch angefangen bei einigen meiner Shopware-Plugins Events einzubauen, so dass diese auch teilweise erweitert werden können. Das Preis-Warnung-Plugin ist das erste, das Events erhalten wird. Bei Shopware ist es an sich sehr einfach mit Events zu arbeiten. Als Beispiel nehmen wir uns einen einfachen Service.
namespace HPrEventTest\Components;
class EventService{
/** @var \Enlight_Event_EventManager */
private $eventManager;
public function __construct(\Enlight_Event_EventManager $eventManager = null){
$this->eventManager = $eventManager;
}
public function fireExample(){
$val = 0;
$result = $this->eventManager->filter('HPrEventTest_example', $val, ['subject' => $this]);
return $result;
}
}
Wir müssen nur noch den Event-Manager per Injection zum Service hinzufügen.
<?xml version="1.0" encoding="utf-8"?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="hpr_event_service" class="HPrEventTest\Components\EventService">
<tag name="service" />
<argument type="service" id="events" />
</service>
</services>
</container>
Wie man auf Events reagiert, weiß eigentlich jeder, der schon mal ein Shopware-Plugin geschrieben. Allein der Klassiker zum hinzufügen von Template-Dirs erklärt schon fast alles.
namespace HPrEventTest;
use Shopware\Components\Plugin;
class HPrEventTest extends Plugin{
public static function getSubscribedEvents(){
return [
'HPrEventTest_example' => 'processEvent',
];
}
public function processEvent(\Enlight_Event_EventArgs $args){
$args->setReturn($args->getReturn() + 1);
}
}
Wir feuern also ein Event mit 0, das wird in unseren Plugin verarbeitet und 0 wird zu 1 und diese 1 wird von der ursprünglichen Service-Methode auch dann wieder zurück gegeben.
Es gibt natürlich noch ein paar mehr Event-Strategien als filter(), aber an sich sind alle sehr ähnlich. Nicht bei jedem wird der Return-Wert verwendet.
Das Subject, das wir hier verwenden, eignet sich super dafür Controller und Services zu übergeben, die das Event ausgelöst haben.
| User | annonyme | 2018-03-09 20:17 |
write comment: