PHP のイベント駆動型の問題に関する私の意見

質問

PHP のイベント駆動の問題について議論している人を見かけたので、このスレッドに返信すべきでした。しかし、この返信だけでは皆さんの注目を集めるのに十分ではないと感じたので、この問題についての私の理解を詳しく説明し、優れた作品について説明および分析した記事を作成しました。

イベント駆動型の概念は幅広いです。クライアント側でもサーバー側でも構いません。

WEBアプリケーションにおいて、クライアント側のイベントはJSやプラグイン、JAVAAPPLETをベースとしていますが、基本的にプラグインやJAVAAPPLETであればHTMLの範疇には属しませんが、JSを使用する必要があります。実際のところ、ほとんどの場合、FORM の送信やリンクのクリックなどの基本的な操作が行われるだけなので、イベントについて話すことは意味がありません。

イベント駆動の本当の意味はビジュアルプログラミングにあるのではなく、OO と同じようにその概念にあります。イベント駆動型は実際には OO の拡張であり、その元のプロトタイプはメッセージ メカニズムです。ただし、イベント ドライバーはメッセージを呼び出し可能な関数にカプセル化します。これは、API のコールバック関数に似ており、これらの関数の実行内容を自分で定義できます。ビジュアル プログラミングでは、これらの関数を分離し、パラメーター (ほとんどの場合は既製のオブジェクト) を定義し、独自のコードを記述してこれらのパラメーター (実際にはこれらのオブジェクト) を使用して何かを実行できるようにします。

つまり、主にフレームワークの設計により、PHP がイベント駆動型になることは完全に可能です。 VB などのいわゆるビジュアル イベント ドライバーを作成するには、ページ デザイン、イベント エンコーディング、コンパイル、トランスコーディングなどの一連の機能を含む、サポートされる統合開発環境が必要です。実際、NET のようなイベント駆動型のものは、ボタンやテキスト ボックスなどの一般的に使用される WEB 要素やコントロールをカプセル化するだけなので、コンパイル後も、< のようなテキストのままで視覚的なインターフェイスを設計できます。 ;input type="text"> の場合は、イベント コードを 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のイベント駆動コードを学ぶのに良い作品であることは間違いありません。したがって、強くお勧めします！