Hallo, ich habe eigentlich die recht triviale Anforderung, ein bestehendes Shopware-Model um eine eigene Methode zu erweitern. Leider sehe ich momentan keine Möglichkeit, mithilfe des jetzigen Event/Hook System dieses Vorhaben umzusetzen. Sehe ich den Wald vor lauter Bäumen nicht ? Wird vielleicht ein bestimmtes Event gefeuert, was man registrieren kann, wenn eine Methode nicht gefunden wird ? Ansonsten hätte ich neben einem Event noch folgenden Vorschlag: Ein Ansatz, eigene Methoden für bestehende Klassen zu definieren könnte sein, per replace-Hook die neue Methode zu registrieren. Leider funktioniert - wenn ich das richtig sehe - das Hook-System nur auf bereits bestehenden Methoden: Die Klasse Enlight_Hook_ProxyFactory guckt in der generateMethods(), ob nur auf den bereits vorhandenen Methoden foreach ($rc-\>getMethods() as $rm) Hooks registriert sind und generiert dafür die entsprechenden Proxy-Methoden. Durch eine relativ kleine Anpassung, könnte man hier doch (IMHO) auch neue Methoden definieren (ausserhalb der foreach bzw. den hookManager durchiterieren). A propos - damit die Bootstrap nicht in einem unübersichtlichen Maß an Callbacks anwächst und nur für Registrierungen zuständig ist, fände ich es toll, wenn man die Listener-Funktionen in Unterklassen auslagern könnte - z.B.: $this-\>subscribeEvent('sAdmin::[METHODE]::after', 'myPlugin\_sAdmin::[METHODE]\_\_after'); Darüber hinaus könnte man sich mit solch einer Konvention das Registrieren in der Bootstrap komplett sparen. just my 2 Cents - und falls es schon eine Lösung für mein Anliegen gibt würde ich mich über eine Antwort freuen und entschuldige mich für meinen Redeschwall 
Ansonsten schöne Ostern, Manuel
*ganz vorsichtig push* In anderen Threads wird so schön vom Shopware Team reagiert… Wurde mein Post zu Ostern vielleicht zu gut versteckt ?
Hallo, kannst du etwas genauer beschreiben, was du vor hast und warum du das so umsetzen möchtest? Eigentlich ist es ja nicht erforderlich, dass du neue Methoden in bestehende Shopware-Komponenten einfügst - das würde ja auch ein Stückweit das Sandbox Prinzip verletzten, auf dem die Plugins aufbauen.
Hallo Stefan, danke für deine Antwort. Konkret habe ich vor, die bestehenden Models um weitere Methoden zu erweitern. Nehmen wir beispielsweise das Order Model. Für ein Zahlungmodul möchte ich prüfen, ob eine gegebene Bestellung mit meiner neuen Modul-Zahlungsart abgeschlossen wurde. Dies könnte man bsp. über: $order-\>getPayment()-\>getId() == 'meineID' lösen. Wäre es jetzt nicht besser, diese Logik im Order-Model zu haben und in verschiedensten Stellen nutzen zu können: public function prefix\_\_isMyPayment() { return $this-\>getPayment()-\>getId() == 'meineID'; } Solche Sachen machen ein ORM ja erst so richtig spannend 
(man denke auch an neue Queries in den Repositories). Eine andere Stelle ist beispielsweise sAdmin. Hier wird in sManageRisks() eine Callback generiert und aufgerufen wobei $rule[“rule1”] aus der Datenbank kommt : $rule["rule1"] = "sRisk".$rule["rule1"]; $this-\>$rule["rule1"]($user,$basket,$rule["value1"]) Wenn wir jetzt neue rules (prefix__myNewRule) definieren, würde dieser Code sRiskprefix__myNewRule() in der sAdmin-Klasse aufrufen. Hier wäre es wieder eine tolle Sache, eigene Methoden für bestehende Klassen zu definieren zu können. Natürlich bringt große Macht auch große Verantwortung, weshalb hier stets mit Prefixen gearbeitet werden sollte damit nicht andere Plugins die gleiche Methode neu anlegen möchten. Darüber hinaus würde ich mich auch über ein kleines Feedback zum 2. Teil meines Postings (Bootstrap) freuen. Danke & Gruß, Manuel
Hallo, habe deine Vorschläge mal komplett in unser internes Wiki übertragen, so dass wir das in der Entwicklung diskutieren können. Sobald es dort News gibt, gebe ich dir einen kurzen Status.
Hi, konntet ihr das schon erörtern ? Gruß, Manuel