Plugin Architecture/Design Pattern - il est préférable d’utiliser un motif privé Observer/Mediator pour les sous-classes de plug-ins ou WP add_action?
Je code un plugin très complexe qui est organisé comme une classe "conteneur" parent et plusieurs sous-classes, où chaque sous-classe est un élément optionnel/obligatoire qui correspond généralement (mais pas toujours) à sa propre add_submenu_page.
En gros, il s’agit d’un plugin avec son ensemble privé appelé "subplugins".
Chaque sous-classe/sous-plugin a ses propres (grands) ensembles add_action et add_filter. Donc, techniquement, le sous-plugin de mon plugin est un plugin valide WP, il n'est simplement pas appelé directement par WP lui-même.
Depuis que j'ai planifié ... en fait des tonnes de add_action ... Je me demande si je devrais refactoriser mon plugin en utilisant un modèle d'observateur/médiateur "privé", c'est-à-dire. collecter tous les add_actions pertinents dans ma classe parente uniquement et créer un modèle pour notifier/transmettre les sous-classes d'événements, réduisant ainsi l'impact de mon plug-in sur WP ques.
Est-ce une bonne idée ou ce n'est absolument pas nécessaire? Pouvez-vous m'aider avec du code pour la refactorisation de classe?
merci d’avance pour obtenir de l’aide, gabriele
Je me demande si je devrais refactoriser mon plugin en utilisant un modèle d'observateur/médiateur "privé", c'est-à-dire. collecter tous les add_actions pertinents dans ma classe parente uniquement et créer un modèle pour notifier/transmettre les sous-classes d'événements, réduisant ainsi l'impact de mon plug-in sur WP ques.
La file d’événements est fondamentale pour WP, elle est donc assez rapide et de plus en plus rapide tout le temps.
Donc, je ne pense pas qu'il soit logique, du point de vue des performances, de créer vos propres sous-files d'attente.
Refactoriser votre code afin de ne pas avoir à passer chaque appel add_action () manuellement est une affaire différente.
Donc… j'ai fondamentalement adopté la même approche, je ne sais pas si c'est correct. Je pense que beaucoup de gens ont recours à cette approche car elle découle naturellement de l’application de configuration api.
- Je définis des modules (= 1 page d'administration, donc en-tête, etc ...) et chaque module a des plugins (les plugins ont des champs, sont 1 objet dérivé de la classe de plugin abstraite.
ici: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-load-configuration.php
Je pense que cela se fait automatiquement par la plupart parce que, par exemple, un module: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-module.php correspond à ce que nous besoin de faire pour les paramètres api
- l'init charge les modules et les plugins (qui ont chacun leurs propres actions de filtrage ou sont rattachés à un filtre ou à des actions) {et un tiers peut ajouter des plugins aux modules}
ici: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-init.php
(où les plugins vérifient s'ils doivent être activés s'ils sont activés sur la page d'administration correspondante) (et peuvent être représentés sous la forme d'un résumé: http://plugins.svn.wordpress.org/ wp-favicons/trunk/includes/class-plugin.php )
un plugin dérivé de la classe de plugin abstraite puis tout ou partie: définit des champs supplémentaires, définit son propre écran d'aide, vérifie ses propres champs, exécute les actions de la page admin, exécute des fonctions côté client telles que des filtres
un plugin se fixe via Addfilter, par exemple: http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/sources/inc/class-module-sources-plugin.php qui correspond à un "filtre" toujours présent dans chaque plug-in. Il peut donc s'agir d'une couche abstraite supplémentaire si plusieurs plug-ins réutilisent le même "do".
et peut attacher à vos propres filtres dans des classes à l'arrière-plan, par exemple. http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/request/request_cache.php ajoute des filtres spécifiques dans le plugin- ajouter un filtre
Ainsi, de de l’autre côté "le site principal", j’ai défini uniquement mes propres filtres, chacun des plug-ins pouvant s’attacher, par exemple. http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/metadata_favicon/inc/class-favicon-factory.php définit des filtres tels que "Config :: GetPluginSlug (). 'search'"
Donc en général ... Je pense que les paramètres de l'API nous amènent naturellement à cette approche.
Alors ... alors certains arrivent au point (votre question) dans lequel vous penseriez de re-factoriser vos propres actions additionnelles à "autre chose" qui pourrait être des modèles d'observateur/médiateur ou toute autre chose.
Mais ... puisque nous avons suivi l'approche WordPress en utilisant les paramètres de l'API (tout ce qui est décrit ci-dessus), cela permet aux tierces parties de "se connecter" à des actions, d'écrire leurs propres extensions de page d'aide, etc. collez ici aussi avec add_action simplement parce que "le reste" de la conception suit également ceci et qu'il est probablement plus facile de comprendre l'ensemble du code.
Un autre exemple intéressant de distribution d'un plugin avec des sous-plugins est celui-ci .