イベント駆動型の概念は幅広いです。クライアント側でもサーバー側でも構いません。
WEB アプリケーションにおいて、クライアント側のイベントは基本的に JS やプラグイン、JAVAAPPLET をベースとしていますが、実際には JS が必要となる場面はありません。実際に使用されるものはそれほど多くはなく、せいぜいFORM送信やリンククリックなどの基本的な操作なので、イベントについて語るのはあまり意味がありません。
イベント駆動の本当の意味はビジュアル プログラミングにあるのではなく、OO と同じようにその概念にあります。イベント駆動型は実際には OO の拡張であり、その元のプロトタイプはメッセージ メカニズムです。ただし、イベント ドライバーはメッセージを呼び出し可能な関数にカプセル化します。これは、API のコールバック関数に似ており、これらの関数の実行内容を自分で定義できます。ビジュアル プログラミングでは、これらの関数を分離し、パラメーター (ほとんどの場合は既製のオブジェクト) を定義し、独自のコードを記述してこれらのパラメーター (実際にはこれらのオブジェクト) を使用して何かを実行できるようにします。
したがって、主にフレームワークの設計により、PHP がイベント駆動型になる可能性は十分にあります。 VB などのいわゆるビジュアル イベント ドライバーを作成するには、ページ デザイン、イベント エンコーディング、コンパイル、トランスコーディングなどの一連の機能を含む、サポートされる統合開発環境が必要です。実際、NET のようなイベント駆動型のものは、ボタンやテキスト ボックスなどの一般的に使用される WEB 要素やコントロールをカプセル化するだけなので、コンパイル後もこのようなテキストのままで視覚的なインターフェイスを設計できます。 、イベントコードをJSまたはサーバーサイドコードに変換するだけです。 PHP の場合、主な理由は、IDE が十分に機能しておらず、プリコンパイル メカニズムがないため、送信された最終コードは、NET リソース コードとイベント コード (通常は ASP) が混在したものではなく、依然として最終的な PHP コードであることです。 XML 仕様に準拠したドキュメントには、非標準の HTML コードが含まれています。したがって、PHP は、誰もが考える狭義のイベント駆動型プログラミングをまだ実現できていませんが、実際にはまったく問題ありません。
興味があれば、 www.php.net の公式ホームページにアクセスして、中国人の友人 (Qiang Xue) が作成したイベント駆動型の PHP フレームワークである PRADO を見てみるのも良いでしょう。 http://www.zend.com/php5/contestを参照してください。そのソース コードを読めば、PHP のイベント ドライバーが何であるかがわかります。しかし、この点に関して、PHP にはプリコンパイルのメカニズムがなく、OO に依存しすぎているため (コードは PHP5 で書かれていますが)、このフレームワークは少し大きく、使用が複雑で、スケーラビリティがあまり高くないと思います。しかし、コンセプトは非常に優れており、いくつかのアイデアは私が何日も悩まされていた問題を解決してくれました。以下にこのフレームワークを簡単に紹介します。
このフレームワークは ZDE と PHP5 で書かれており、詳細なドキュメント、非常に明確な構造、および十分なコメントがあり、作成者のコーディング レベルが非常に高いことがわかります。著者は、このフレームワークが ASP.NET と Borland Delphi の概念を参照していると明確に述べています。
このフレームワークは検証に非常に強く (検証ログインなどのモジュールはありません)、非常に堅牢であり、外部から侵入できる直接的な抜け穴があることはほとんど不可能です。仕様ファイルの概念が導入されています。この検証方法の唯一の問題は、仕様ファイルの作成自体がより手間がかかることです (もちろん、ツールの使用は別の問題です)。仕様ファイル自体 (フォーマットと仕様を含む) の検証は、毎回人間が呼び出す必要がなく、フレームワークによって自然に行われます。そのイベントは仕様ファイルで定義することもできます (これは必要ないと思います)。実際、その仕様ファイルは DELPHI または VB の FORM 定義ファイルに似ていますが、XML ではなくプレーン テキストです。視覚化。イベント駆動に関しては、フレームワークには NET と同様の基本的なイベント フローが組み込まれており、これらのイベントをさまざまな段階でカスタマイズできます。これは、OnXXX 関数を再定義し、パラメーターを使用することを意味します。たとえば、独自のコンポーネントを定義するときに、コンポーネントが持つ可能性のあるイベント関数とパラメータを将来的に定義することもできます。コンポーネントを使用する場合 - しかし、この方法は複雑すぎて、大量の XML ファイルを読み取って分析する必要があると思います。これは非常に厳密で安全ですが、少し過剰であり、PHP 自体の柔軟性を十分に活用していません。私のアイデアは、DELPHI に似たものを使用することです。関数ハンドルを割り当てるか、C のコールバック関数の機能を使用すると、コードを記述しているときにいつでもどこでもイベントを定義でき、イベントの送信者とタイプを明確に識別できます。機械を必要とせずに十分なセキュリティが保証されるため、各コンポーネントに特定のイベントのみを持たせることができ、コードの変更や拡張が非常に便利になります。もちろん、大規模なプロジェクトに取り組む場合は厳密な定義が必要ですが、それでもフレームワークのイベントの処理方法はやや時代遅れです。
そのテンプレートはコンパイル前の NET の ASP ファイルに似ていますが (ASP NET には詳しくありませんが、いくつかの原理は理解しています)、仕組みは DELPHI に似た FORM ファイルです。これは非常に良い概念です。唯一の欠点は、相互に排他的な複数のコンポーネントを 1 つのテンプレートに同時に組み合わせて、どのコンポーネントのみを表示するかを決定できるため、DW などの WYSIWYG 一般エディターを使用するのがあまり便利ではないことです。実行時。
このフレームワークのコードを見ると、まだ非常に弱い項目がいくつかあることがわかります。最も重要なのは、スケーラビリティが非常に低いことです。これは、専用ホストに適しているはずです。一部の制限付きホスト (ディレクトリ制限や権限制限) については何もできず、対応するリマインダー措置もありません。関連するインターフェースはありません)。特定のリソースまたはファイルのパスには、assetService と呼ばれる面倒なメカニズムが使用されます。これは、作成者自身も、このサービスを使用するとシステムの消費量が大幅に増加すると述べています。 FLASH のアセット ライブラリの概念により、パスを任意に指定できますが、毎回再検証する必要があり、メリットがありません。私のアプローチは、いくつかのメイン パスを固定し、そのサブディレクトリは任意にすることで、この 2 つの間の矛盾のバランスを総合的にとることです。パスの問題が考慮されていないため、フレームワークは言語設定やパーソナライズされたテンプレートなどに関して無力です。プロジェクトを翻訳しようとすると、手順が複雑で作業量が膨大で、簡単に翻訳できないことが考えられます。間違いを犯す。これは、このフレームワークに関する唯一の最も深刻な問題です。
一般的に言えば、このフレームワークのコンセプト、デザイン、コードは間違いなく一流です。もちろん、常に欠点はありますが、だからといって学習や学習が妨げられるわけではありません。私はそのコードをすべて読んだわけではなく、いくつかのコアプログラムといくつかの説明書を読んだだけですが、その構造とアイデアははっきりとわかり、著者を深く尊敬していますが、欠点も深く残念に思っています。何はともあれ、PHPのイベント駆動コードを学ぶのに良い作品であることは間違いありません。したがって、強くお勧めします！