Plugin Architecture / Design Pattern – ist es besser ein privates Observer / Mediator Pattern für Plugin Subclasses oder WP add_action zu verwenden?

Ich schreibe ein sehr komplexes Plugin, das als übergeordnete “Container” -class und mehrere Unterklassen organisiert ist, wobei jede Unterklasse ein optionales / obligatorisches Element ist, das normalerweise (aber nicht immer) seiner eigenen Seite add_submenu_zuordnet.

Im Grunde genommen handelt es sich um ein Plugin mit seinem privaten Satz von “Subplugins”.

Jede Unterklasse / Subplugin hat ihre eigene (große) Menge von add_action und add_filter. Technisch gesehen ist das Plugin also ein gültiges WP-Plugin, einfach nicht direkt von WP selbst aufgerufen.

Da ich geplant habe … eigentlich Tonnen von add_action … Ich frage mich, ob ich mein Plugin mit einem ‘privaten’ Beobachter / Mediator Muster umgestalten sollte. Sammeln Sie alle relevanten add_actions nur zu meiner Elternklasse und erstellen Sie ein Muster, um Unterklassen von Ereignissen zu benachrichtigen und weiterzuleiten, wodurch die Auswirkung meines Plugins auf WP-Ereignisfragen reduziert wird.

Ist es eine gute Idee oder ist es absolut nicht notwendig? Kannst du mir mit Code für das classn-Refactoring helfen?

tnx im voraus um Hilfe, gabriele

Solutions Collecting From Web of "Plugin Architecture / Design Pattern – ist es besser ein privates Observer / Mediator Pattern für Plugin Subclasses oder WP add_action zu verwenden?"

Ich frage mich, ob ich mein Plugin mit einem ‘privaten’ Beobachter / Mediator-Muster umgestalten sollte. Sammeln Sie alle relevanten add_actions nur zu meiner Elternklasse und erstellen Sie ein Muster, um Unterklassen von Ereignissen zu benachrichtigen und weiterzuleiten, wodurch die Auswirkung meines Plugins auf WP-Ereignisfragen reduziert wird.

Die Ereigniswarteschlange ist grundlegend für WP, also ist sie ziemlich schnell und wird immer schneller .

Also, ich denke nicht, dass es einen Sinn macht, eigene Subqueues zu erstellen.

Das Refactoring Ihres Codes, damit Sie nicht jeden Aufruf von add_action () manuell vornehmen müssen, ist eine andere Sache.

Also … ich habe im Prinzip den gleichen Ansatz gewählt, weiß nicht, ob es korrekt ist. Ich denke, viele Leute kommen zu diesem Ansatz, da es natürlich aus den Einstellungen api herauskommt.

  • Ich definiere Module (= 1 Admin-Seite, also Header, etc …) und jedes Modul hat Plugins (Plugins haben Felder, sind 1 Objekt von abstrakten Plugin-class abgeleitet.

hier: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-load-configuration.php

Ich denke das wird von den meisten automatisch gemacht, weil zB ein Modul: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-module.php was wir für die Einstellungen api tun müssen entspricht

  • Die init lädt die Module und Plugins (die jeweils eigene Filteraktionen haben oder an Filter oder Aktionen anhängen) {und Drittanbieter können Plugins zu Modulen hinzufügen}

hier: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-init.php

(wo die Plugins prüfen, ob sie aktiviert werden sollen, wenn sie auf der entsprechenden Adminseite aktiviert sind) (und können als Abstract dargestellt werden: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class) -plugin.php )

Also von der anderen Seite “die Backend-Site” habe ich nur meine eigenen Filter definiert, in denen sich jedes der Plugins anhängen kann zB http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/metadata_favicon/inc/ class-favicon-factory.php definiert Filter wie “Config :: GetPluginSlug (). ‘search'”

Also im Allgemeinen … denke ich, dass uns die Einstellungs-API zu diesem Ansatz führt.

Also … dann kommen einige zu dem Punkt (deine Frage), in dem du denken würdest, deine eigenen Add-Aktionen zu “etwas anderem” zu reaktorisieren, das Beobachter / Mediator-Muster oder irgendetwas anderes sein könnte.

Aber … da wir den WordPress-Ansatz mit der Einstellungs-API (die ganze Sache oben) befolgt haben, indem wir dies so verwenden, dass es Drittanbietern leicht ist, sich in Aktionen einzuklinken, schreiben Sie ihre eigenen Hilfeseiten-Erweiterungen etc … würde ich kleben Sie auch hier mit add_action, nur weil “der Rest” des Designs auch diesem folgt und es es wahrscheinlich einfacher macht, den ganzen Code zu verstehen.

Ein weiteres schönes Beispiel für die Verteilung eines Plugins mit Sub-Plugins ist dieses .