4

スタックオーバーフロー！

プラグインのような (呼び出し方がわからなかった) Web アプリケーションを PHP で作成する方法を探しています。つまり、ユーザーがブラウザーを介して (構成にコードを追加するのではなく) プラグイン (必要に応じて拡張機能) を追加/削除できるシステムを作成したいと考えていました。私の意見では、良い例はWordPressです。エンドユーザーは、あらゆる種類のプラグインを簡単にインストールでき、ほとんど何もしなくても期待どおりに動作し、多くの場合、多くの設定を変更する必要があります。

また、できるだけ使いやすいものにしたいと思っています。つまり、プラグインは他のプラグインの一部を使用できるため、コードの書き換えが少なくて済みます。たとえば、承認/認証用のプラグインや、ユーザーに関連するその他すべてのものがあります。次に、ブログ用のプラグインです。もちろん、ブログには前述の必要がありますよね？したがって、前述のプラグインを使用して機能するだけです。依存関係などがたくさんあることは理解していますが、それは正常です。:)

私の質問は...どのようなテクニックでそれを達成できますか? そのようなシステムの長所と短所は何ですか? 少し遅くなり、Facebook のような非常に巨大なサイトには適合しないと思います (わかりました、それは大きすぎます)。

イベント駆動型プログラミング (またはイベントベース プログラミング) について聞いたことがあり、ウィキペディアでそれに関する記事を読んだことがありますが、それでも... 非常に混乱しており、さらに、それが自分のことなのか確信が持てません。探している。

これを読んでくれてありがとう。可能であれば、いくつか答えてください。:D

4

2 に答える 2

6

考慮すべき問題は複数あります。ご指摘のとおり、プラグイン システムは拡張機能をアプリケーションに登録することに依存しており、拡張機能自体はメイン アプリケーションにフックする方法が必要です。

そのすべての欠点に対して、Wordpress にはこれに対する非常に実行可能なアプローチがあります。プラグインとのインターフェースに「フック」を使用します。これは基本的に、多かれ少なかれ「イベント駆動型」にもなり得るコールバックシステムです。基本的に、メイン アプリケーションは次のようなことを行います。

foreach ($callback["need_to_render_sidebar"] as $fn) {
    $fn();
}

ただし、追加のパラメーターを渡したり、データを返したりすることで、より柔軟にすることができます。さらに重要なこととして、より複雑な機能に対して手続き型のコールバックではなくオブジェクトを使用することもできます。(私は組み合わせることをお勧めします。すべてのアプリケーションまたは拡張機能に適した 1 つのアプローチはありません。)

同様に、プラグイン システムを使用すると、拡張機能自体がメイン アプリケーションをコールバックしたり、データをフィードしたり、設定を変更したりできるようになります。

プラグイン システムについて考慮する必要がある 2 番目の部分は、それを管理しやすくする方法です。基本的に、各 WebCMS/DMS には独自のアプローチがあります。多くの場合、zip ファイルを使用して手動で抽出するか、モジュール ディレクトリを使用します。手始めに、メタデータ拡張スクリプト ファイルの WP のようなアプローチが最適です。かなりラフですが、WP とは独立して使用できる同様のシステムを作成しました。

于 2011-08-09T11:37:22.110 に答える
2

単純な概念です。

拡張機能を PHP クラスとして使用し、それらを 1 つ (または複数) のディレクトリ (-ies) 内の個別のファイルに格納できます。拡張機能ファイルを調べてこれらのクラスのオブジェクトを作成することにより、メイン アプリケーションで拡張機能を初期化する必要があります。

新しい拡張子を追加するには、新しいクラス ファイルをディレクトリに追加します。拡張機能内に有効化/無効化機能を追加するか、メイン アプリケーションで管理することもできます。

于 2011-08-09T11:37:32.767 に答える