mir ist das Subscriben auf die Events durch die Dokus noch nicht vollständig klar geworden. In der Doku finde ich auch nur zwei Beispiele, welche es mir nicht ganz erläutern.
Ich habe daher verschiedene Fragen:
Wie kann ich die korrekten Events für mein Plugin herausfinden? Kann man die irgendwo in der Konsole sehen, oder muss ich mir diese dazu beispielsweise anhand der /Storefront/Page Struktur ableiten?
Wo findet man diesen hier: ProductEvents::PRODUCT_LOADED_EVENT Das ist ja kein reines Storefront Event, sondern könnte ja auch im Admininstrationsbereich sein.
Dieses Event (ProductPageCriteriaEvent::NAME) habe ich gefunden unter /Storefront/Page/Product. Wieso aber „::NAME“ dazu kommt weiß ich nicht…?
Kann jemand mal ein paar Beispiele aufzeigen, z.B.: ein Event das greift, sobald die Storefront aufgerufen wird und ein Event sobald ein Listing aufgerufen wird?
nicht mehr alles, was du in SW5 mit Events lösen musstest, muss nun in SW6 auch über Events geschehen. Viel läuft über das Decorator Pattern, viel über Tagged Services.
Das hängt also stark davon ab, was du zu erreichen versuchst.
Ich versuche mal deine Fragen zu beantworten:
Es gibt ganze Klassen, die nur alle möglichen Events einer Entität auflisten, und es gibt einzelne Klassen, die ein Event selbst darstellen.
Die Ersteren findest du, wenn du im Code nach “@Event” suchst. Hier habe ich die Suche einmal für dich in GitHub ausgeführt.
Die Letzteren findest du, indem du nach “extends NestedEvent” oder “extends Event” suchst. Auch hier und hier einmal die Suche dazu.
Im Zusammenhang mit der Antwort aus 1.: Wenn du dir das Suchergebnis anschaust, siehst du, dass jedes Event einer Entität mit der @Event Annotation markiert ist. Diese zeigt auch an, wo das Event genutzt wird, in deinem Fall zum Beispiel in der Klasse EntityLoadedEvent. Hinter der Konstante “PRODUCT_LOADED_EVENT” steckt ja der String “product.loaded”. In der verlinkten Zeile siehst du, dass ein Event hier nach dem Muster “.loaded” gesucht wird. Heißt: Die werden dynamisch pro Entität (Produkte, Kunden, Kategorien, …) ausgeführt.
Du hast aber Recht: Dieses Event wird auch in der Administration ausgeführt. Immer dann, wenn eine Produkt-Entität geladen wird. Das passiert sowohl in der Administration, als auch in der Storefront und der API.
Es gibt, wie oben beantwortet, Klassen, die ein Event selbst darstellen. Diese verfügen dann über eine “NAME” Konstante, die den eigentlichen Namen des Events beinhalten. So auch in diesem Fall.
Okay, es ist ein bisschen anders als in SW5, aber ich versuche mich da einzuarbeiten. Ohne Symfony wirklich zu kennen ist es als Webdesigner etwas schwierig bei dem ganzen Klassen- und Entitäten-Dschungel durchzublicken
Okay, wie ich ein Event finde habe ich soweit begriffen.
Wenn ich jetzt ein Plugin global an das Rendern der Storefront binden möchte, wäre dann das Event StorefrontRenderEvent vergleichbar mit dem Enlight_Controller_Action_PostDispatchSecure_Frontend aus SW5?
Ich weiß, dass es auf Grund der service.xml bums ist, in welchen Ordner ich den Subscriber lege… Prinzipiell gibt es hin und wieder auch Funktionen, welche für mehrere Subscriber gleich wären… dahingehend finde ich Variante aus Punkt 1 besser, da ich hier allgemeinere Suibscriber-Bezeichnungen wählen kann und mich auch auf ein Array an Events subscriben könnte…
Bzgl 1.:
Ich finde es schwierig hier Events zu vergleichen. Im Groben kann man das so sagen, ja.
Es gibt natürlich trotzdem ein paar Unterschiede.
Bzgl. 2.: Prinzipiell freut es mich erstmal, gesehen zu haben, dass du selbst verstanden hast, dass es vollkommen egal ist, wo du deinen Subscriber hinlegst.
In Shopware 6 haben wir bewusst versucht, den Plugin-Herstellern möglichst viel Spielraum zu bieten. So ist es nun ja sogar auch möglich selbst zu entscheiden, wo die Plugin Base Class (früher die Bootstrap) liegt - man muss sie nur in der composer.json entsprechend vermerken.
Und ebenso ist das bei den Subscribern.
Wir haben intern beide Fälle hier und da abgedeckt.
Die Kritierien waren meist relativ simpel:
Hast du ein kleines überschaubares Plugin? Dann leg’ die Subscriber beispielsweise in einen Subscriber Ordner. Da hast du sie alle gesammelt.
Ist dein Plugin jedoch riesig, hat Unmengen an Features und Bereichen, in denen es eingreift?
Dann kann es Sinn ergeben, die Subscriber anderweitig aufzuteilen.
Beispielsweise könnte es sein, dass du jede Menge im Checkout, und jede Menge auf der Detailseite änderst und für jeden Bereich 5-6 Subscriber hast.
Da würde es ja Sinn ergeben, jeweils innerhalb des Bereiches, also Checkout / Detail, einen Subscriber Ordner zu haben.
Bevor du das anmerken willst: Mir ist bewusst, dass dies beim Bundle Plugin nicht der Fall ist.
Da liegt der Subscriber jedoch in etwa in dem Ordner, in dem auch die Klasse liegt, die der Subscriber über Events anpasst.
Am Ende muss da jeder für sich selbst eine für sein Plugin sinnvolle Struktur finden.
Das ist bestimmt auch eine Geschmackssache und alles hat Vor- und Nachteile.
Daher in kurz: Wie es für dein Plugin, deinen Anwendungsfall am Besten passt.
