Hi, kann man auch Hooks / Subscribes auf Models realisieren? Beispielsweise möchte ich im Model /Media/Media.php die Funktion uploadFile() erweitern mit einem „Hook:After“ funktioniert das? Hier nochmal der exakte Link zur Funktion https://github.com/ShopwareAG/shopware- … a.php#L730
Hi, konntest du dein Problem bzgl. dieser Frage lösen? Haben nämlich gerade das gleiche Problem. Viele Grüße, Edin
Hi nochmals an alle, vielleicht kann seitens Shopware eine Auskunft gegeben werden, welche Klasse denn nu hookable sind. Im Tutorial für Events und Hooks, steht dass fast alle Objekte mit Hooks angesprochen werden können. Soweit ich das erkennen kann, sind es bei Modellen die aber nur Reopsitory Klassen. Es wäre aber praktisch, wenn man dies auch auf die restlichen Klassen ausweiten würde. Ich wollte z.B. gern den Medien Manager erweitern, so dass man beim Erstellen der Thumbnails erweiterte Bilderstellungsoptionen angeben. Die Anpassung des Frontends über die Blocks ist kein Problem. Um die Bilderstellung anzupassen muss ich aber die createThumbnail Methode überschreiben. Da käme ein Replace Hook ganz gelegen. Die Klasse scheint aber nicht hookable zu sein. Über jeden Hinweis wäre ich sehr dankbar! Viele Grüße, Edin
Sorry, dass ich nochmals damit nerve, aber ist leider dringend. Also wäre ich für jeden Hinweis dankbar, ob das geht oder nicht. Damit ich weiss ob ich die Hooks bei Media.php wirklich ignorieren soll und das ganze quasi komplett von der Hand schreiben muss. Viele Grüße, Edin
Hi, [quote]…eine Auskunft gegeben werden, welche Klasse denn nu hookable sind.[/quote] Eine ganz einfache Antwort gibt es da nicht, das ist etwas technisch: Die Hooks sind ja über ein Proxy-Pattern umgesetzt, entsprechend müssen Klassen, die gehookt werden sollen, über so einen Proxy geladen werden (die Dinger in cache/proxies). Die entsprechende Methode „getProxy“ findet sich im HookManager von Enlight. Eine Klasse ist also hookable, wenn sie nicht direkt, sondern der dazugehörige Proxy instantiiert wird. Ein schönes Beispiel sind bspw. die Controller. Die werden im Enlight_Controller_Dispatcher_Default wie folgt instantiiert: $proxy = Enlight\_Application::Instance()-\>Hooks()-\>getProxy($class); /\*\* @var $controller Enlight\_Controller\_Action \*/ $controller = new $proxy($request, $response);
(Wegen der Pre- und PostDispatch-Events kann man bei den Controllern aber oft auf die Hooks verzichten). Das gleiche wird im Standard bei den Core-Klassen gemacht (/var/www/shopware-4/engine/Shopware/Components/Modules.php::loadModule) und bspw. auch bei den Model-Repositories (\Shopware\Components\Model\ModelManager::getRepository). D.h. Controller, Repositories und Core-Klassen sind durch diesen Extra-Schritt beim Laden hookable. Entsprechend sollten sie auch nicht direkt mit „new“ instantiiert werden, weil dadurch die Proxies nicht geladen werden. Weiterhin gibt es noch \Enlight_Class::Instance. Diese statische Methode ist eine etwas generische Möglichkeit, Klassen zu instantiieren. Hier wird automatisch ein Proxy erzeugt oder ggf. eine schon bestehende Instanz zurück gegeben. Wenn du im SW-Code nach „Enlight_Class::Instance“ suchst, findest du bspw., dass Shopware_Components_Document oder die Marketing-Aggregate-Komponenten so erzeugt werden. Die sind also dadurch hookable. => Models sind nicht hookable, weil sie ja entweder durch den Nutzer direkt oder durch Doctrine instantiiert werden. Dafür werden aber nie Proxies genutzt => Hookable ist, was nicht direkt, sondern durch durch einen Proxy instantiiert wird. Das kann entweder durch Laden des von Hooks()->getProxy() zurückgegebenen Proxies erfolgen oder mit Enlight_Class::Instance. Habe das gestern kurz mit einem Kollegen besprochen, das sollte einen groben Einblick geben. Falls ich was übergangen habe, lasse ich mich natürlich gerne korrigieren :). lG Daniel
Danke für die Antwort, Hook wäre für mein Vorhaben schon praktisch, geht aber anscheinend nicht. Muss dann wohl mir was anderes einfallen lassen. Gibt es denn Pläne, die Hooks mit der Zeit auf alle Klassen zu erweitern, oder wird sich dies auf bestimmte Bereiche beschränken, so wie derzeit üblich. Schön wäre ein Hook System, wie bei Wordpress bzw. Drupal, wo man nahezu überall sich einklinken kann. Eine weitere tolle Sache wäre, wenn mann irgendwie die Shop Konfiguration auch in eine Datei exportieren könnte, was mir von Drupal und Features Modul bekannt ist (da wird die Konfiguration in einer PHP Datei in Arrays gespeichert). es sorgt dafür dass die konfiguration in einer datei abgelegt wird, und diese wird einfach mit der datenbank synchronisiert: man konfiguriert lokal den shop, exporiert in die datei, auf remote host, wird diese datei importiert und die shops sind identisch konfiguriert. so ließe sich die konfiguration problemlos versionieren und man könnte eigene konfigurationspakete schnüren, ohne die db mitausliefern zu müssen. dadurch könnte man die artikeldaten und config daten voneinander trennen, also die konfiguration sogar nachträglich importieren. Drupal geht soweit, dass auch alle Plugins ihre Konfiguration exportieren lassen. Mal so als ne Anregung für die Zukunft Viele Grüße, Edin
Hi, mit den Hooks ist das so eine Sache: Damit könnt ihr euch ja auf alles setzen, was public oder protected ist. Wenn wir eine Methode mal refaktorieren / umbenennen / die Parameter ändern, kann euer Hook ggf. schon nicht mehr funktionieren. Das macht das Warten der Software nicht einfacher - einfach weil alles immer in pot. Bruch sein kann. Von daher ist da ein gesunder Mittelweg sicher schon wünschenswert. Das Problem in diesem Fall ist mMn weniger das Hook-System, als das Media-Model: Das enthält einfach zu viel Logik - was uns auch bewusst ist. Da wird es hoffentlich mal eine bessere Lösung geben, in der 4.2 werden meines Wissens schon Teile des Media-Handlings verbessert. Was die Configs angeht: Ich denke, dass man solche Tools auch ganz gut shopware-extern schreiben kann, also gewissermaßen als Deploy-Skripte. Mit den Commandline-Tools, die mit der 4.2.0 kommen, wird das vll. auch noch ein ganzes Stück einfacher. Schöne Grüße, Daniel
Hi, bin dann mal auf 4.2 gespannt. Danke nochmals für die detailierten Einblicke, coole Sache. Und schöne Feiertage, guten Rutsch etc. noch dazu Viele Grüße, Edin
Hallo, ich kann mich dem Wunsch von edin nach hookable Models nur anschließen. Wenn Entitäten auch nur weitere Felder / Attribute erhalten sollen - die vielleicht ausreichend gegen Updates markiert sind - braucht es in den Modelklassen schon zumindest entsprechende Getter und Setter (und Repository-Klassen dürften erweitert werden müssen). Damit hier generell die Erweiterungen instanziiert werden und nicht die Original-Model-Klassen, wäre die Nutzung von Hooks wohl optimal. Hat jemand hierfür eine Alternativlösung? Gibt es in der 4.2 oder in den nächsten Monaten die Absicht, die Doctrine-Einbindung etc. auf „Model-Hooks“ zu trimmen?
[quote=„inco_7“] Gibt es in der 4.2 oder in den nächsten Monaten die Absicht, die Doctrine-Einbindung etc. auf „Model-Hooks“ zu trimmen?[/quote] Hi inco_7, die Models werden auch in Zukunft nicht Hookbar gestaltet. Für die Erweiterung von Datensätzen sind die sogenannten Attribute-Tabellen/Models angedacht. Gruß Oliver
Hi, ja, die *attribute-Tabellen sind dafür gedacht, um eigene Felder erweitert zu werden, das macht man mit der addAttribute-Methode, die wird bspw. im Schuhgrößen-Beispiel genutzt: http://wiki.shopware.de/Einsteiger-Schu … _1052.html Anschließend kann man mit “generateAttributeModels” die Attribut-Model neu generieren lassen, d.h. die Doctrine-Models werden dann anhand der Datenstruktur deiner Attribut-Tabelle neu generiert, so dass du dann dein eigenes Attribut hast. lG Daniel
Gibt es bei den Attributen auch die Möglichkeit Beziehungen anzugeben? Beispiel ich habe ein neues Model in meinem Plugin erstellt. Dieses Model hat eine Beziehung zu einem Artikel Model. Nun möchte ich aber über einen Artikel auf mein neues Model zugreifen folglich müsste ich im Artikel Model eine Beziehung zu meinem Model definieren. Meine Idee war nun ein neues Artikel Attribute hinzuzufügen mit einer Beziehung zu meinem Model. Allerdings finde ich gerade keine Möglichkeit dies bei der Funktion “addAttribute” zu definieren.
Hallo Daniel, danke Daniel, das war es was ich gesucht habe, ich werde mir das en detail zu Gemüte führen. [quote=„ronnybaumann“] … Meine Idee war nun ein neues Artikel Attribute hinzuzufügen mit einer Beziehung zu meinem Model. Allerdings finde ich gerade keine Möglichkeit dies bei der Funktion „addAttribute“ zu definieren.[/quote] Genau das wäre auch mein Problem bei mehreren zusätzlichen Models.