web-dev-qa-db-ja.com

プラグインアーキテクチャー/デザインパターン - プラグインサブクラスにはプライベートObserver/Mediatorパターンを使用する方が良いです。 WP add_action？

私は、親の "container"クラスといくつかのサブクラスとして構成された非常に複雑なプラグインをコーディングしています。各サブクラスはオプションの/必須の要素で、通常は自分自身のadd_submenu_pageにマップします。

基本的には、それを彼のプライベートセットを "サブプラグイン"と呼びましょうというプラグインです。

すべてのサブクラス/サブプラグインには、それぞれ独自の（大きな）add_actionとadd_filterのセットがあります。技術的に言えば、私のプラグインのサブプラグインは有効なWPプラグインです。単にWP自体から直接呼び出されることはありません。

私は計画していたので...実際にはたくさんのadd_action ...プラグインを '非公開の' Observer/Mediatorパターンを使ってリファクタリングするべきかどうか私は思っています。関連するすべてのadd_actionsを私の親クラスのみに収集し、イベントのサブクラスを通知/転送するためのパターンを作成し、私のプラグインがWP event questionに与える影響を軽減します。

それは良い考えですか、それとも絶対に必要ではありませんか？クラスのリファクタリングのためのコードを手伝ってくれる？

事前にt​​nxの助けを借りて、gabriele

plugin-developmentdesignoop
3
Gabriele B

私は私のプラグインを「私用」のObserver/Mediatorパターンを使ってリファクタリングするべきかどうか疑問に思います。関連するすべてのadd_actionsを私の親クラスのみに収集し、イベントのサブクラスを通知/転送するためのパターンを作成し、私のプラグインがWP event questionに与える影響を軽減します。

イベントキューはWPにとって基本的なものなので、かなり高速で、 常に速くなります 。

だから、私はそれがあなた自身のサブキューを作ることに意味があるとは思えない、性能的に賢明ではないと思う。

各add_action（）を手動で呼び出す必要がないようにコードをリファクタリングすることは別の問題です。

2
scribu

だから...私は基本的に同じアプローチを取った、それが正しいかどうかわからない。私は多くの人々がこの設定アプローチを使うことから自然に出てくるのでこのアプローチに来ると思います。

  • 私はモジュール（= 1管理ページ、ヘッダなど）を定義し、各モジュールはプラグインを持っています（プラグインはフィールドを持っていて、抽象プラグインクラスから派生した1つのオブジェクトです）。

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

私はこれがほとんどの人によって自動的に行われると思います。モジュール： http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-module.php は私たちのものに対応します設定APIのためにやる必要がある

  • initはモジュールとプラグイン（それぞれ独自のフィルタアクションを持つか、フィルタまたはアクションにアタッチする）をロードします。{そしてサードパーティはプラグインをモジュールに追加することができます}

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

（対応する管理者ページでプラグインが有効になっている場合に有効にする必要があるかどうかをプラグインが確認する場所）（およびabstractとして表すことができます。 http://plugins.svn.wordpress.org/ wp-favicons/trunk/includes/class-plugin.php ）

だから反対側から "バックエンドサイト"私は自分自身のフィルタを定義しました。 http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/metadata_favicon/inc/class-favicon-factory.php 定義「Config :: GetPluginSlug（）。 'search'」などのフィルタ

だから一般的に...私は設定APIが自然にこのアプローチに私たちを駆り立てると思う。

それで…それから、あなたは自分自身のアドアクションを「何か他のもの」にリファクタリングしてオブザーバ/メディエータのパターンやその他のものにすることができると考えるようになると思われる点（あなたの質問）に来ます。

しかし、...設定APIを使用してWordPressのアプローチに従ったので（上記のすべてのこと）、これを使用することでサードパーティがアクションを「フックイン」するのを簡単にし、独自のヘルプページ拡張などを書くことができます。デザインの残りの部分もこれに従っているので、コード全体を理解しやすくするために、add_actionを使用してください。

3
edelwater

サブプラグイン でプラグインを配布するためのもう1つの良い例はこれ です。

0
kaiser