問題タブ [front-controller]

フロントコントローラーパターンで使用される、さまざまなアクションに使用されるサーブレットがあります。投稿されたデータがenctype="multipart / form-data"であるかどうかを判断できるかどうか誰かが知っていますか？これを決定するまでリクエストパラメータを読み取ることができないため、適切なコントローラにリクエストをディスパッチできません。

何か案は？

Djangoや RoR に見られるような URL インタープリター/ディスパッチャーを PHP で実装する最良の方法は何ですか?

次のようにクエリ文字列を解釈できる必要があります。

• /users/show/4にマップします
  • 面積＝利用者
  • アクション=ショー
  • ID = 4
• /contents/list/20/10にマップします
  • エリア＝内容
  • アクション=リスト
  • 開始= 20
  • カウント= 10
• /toggle/projects/10/activeにマップします
  • アクション=トグル
  • 面積＝プロジェクト
  • ID = 10
  • フィールド=アクティブ

クエリ文字列は、指定された GET / POST 変数、またはインタープリターに渡される文字列にすることができます。

編集: mod_rewrite を使用しない実装を希望します。

編集: この質問はクリーン URL に関するものではなく、URL の解釈に関するものです。Drupal は mod_rewrite を使用して、 http://host/node/5などのリクエストをhttp://host/?q=node/5にリダイレクトします。次に、$_REQUEST['q'] の値を解釈します。私は通訳の部分に興味があります。

私は現在、データベースを使用してページ オブジェクトをセットアップするカスタム フレームワーク内で作業しています。ページ オブジェクトには、フロント コントローラーが MVC (明らかに) パターン内でルーティングなどを処理するために使用するモジュール、ビュー、コントローラーなどに関する情報が含まれています。

データベース内でページを処理する最初の理由は、管理インターフェース内からオンザフライで新しいランディング ページを作成できるようにする必要があり、他の動的オブジェクトをアタッチできる onLoad および onUnload イベントも作成する必要があったためです。

しかし、昨日この投稿を読んだ後、この処理をデータベースの外に移動し、データベースをコンポーネントにすることなくページをテストできるように、すべてのファイル構造とコードを他のフレームワークのように駆動するべきではないかと考えました。

私は現在、カスタム フレームワークを廃止し、標準フレームワークの 1 つを使用してそれを拡張するかどうかを検討しています (これが現在最も可能性が高いことです)。または、フレームワークに付属するルーティング/処理メカニズムをそのまま使用する必要があるか?

私は最近、この投稿を読み、すべてが同じ考えを示唆しているように見える一連の他の投稿につながりました: モデルはすべてを行い、ビューはモデルと直接通信できる必要があり、コントローラーは邪魔にならないようにします。ただし、示されている例はすべてかなり単純化されており、リクエスト/レスポンス サイクルの完全な処理を実装しようとした例を実際に示している例はありません。 $_GET、$_POST など) 自体は?" 「コントローラーは、必要なモデルをインスタンス化し、モデルをビューに渡すためのパススルーとしてのみ動作する必要がありますか?」。(実際、モデルに Zend_Form オブジェクトを埋め込む極端な例を 1 つ見つけました)

Fowler が MVC とコントローラーについて一般的に述べていることを読んだところ、一見したところ、コントローラー レイヤーが薄いほど優れているように思えます。しかし、私は時間をかけて MVC とフロント コントローラーの両方について彼が言っていることを調べました (両方のパターンがコントローラーを定義するため、混乱を招くだけです)。 MVC で Controller の機能を実行し、Front Controller で Command オブジェクトの機能を実行する複合オブジェクト (またはそのようなもの)。

したがって、アプリに同様のパターンを実装した他の人の一般的な意見はどうなるのだろうかと思います-コントローラーレイヤー内でリクエストを完全に処理しますか、それともモデルにリクエストを認識させ、モデル内でパラメーターを直接処理しますか?

私は現在、各ページのファイルを使用してすべての Web サイトをデザインし、ヘッダー、フッターなどの共通要素を含めています。しかし、多くのフレームワークと CMS が Front Controller パターンを使用していることに気付きました。

フロントコントローラーを使うメリットとデメリットは？最終的なシステムにどのページが存在するかがわからないため、パターンは単にフレームワークと CMS で使用されるだけですか?

コンテキスト: mod_rewrite (子ページをロードするフロント ページ) を使用してアプリをビルドしようとしましたが、フロント コントローラー ページから session_enabled ページをロードする際に行き詰まりました。

問題: 問題は、session_start() 呼び出しを 2 回使用すると、PHP ページが応答を停止することです。奇妙なことに、session_start 関数は無害であり、別のページで呼び出されます。

問題を次のサンプルに絞り込みました。

child.php ファイル:

parent.php ファイル:

parent.php を呼び出すと、ブラウザが無限に読み込まれます。session_start() 呼び出しの 1 つにコメントするとすぐに、すぐに読み込まれます。

問題の原因は何ですか? セッション対応のページがどうしても必要です。

PSページを含めることで回避できますが、URLパラメーターに依存しているため、ある種のパラメータープロキシのためにそれらを修正することは避けたいと思います。

デスクトップアプリでは、通常、ビューの管理と選択はどのように行われますか？FrontControllerはWebアプリで人気のあるパターンですが、たとえばネストされた子ビューを選択するよりもページを選択する方が簡単なので、デスクトップアプリケーションにはあまり適していないように感じます。

メインのアプリビューは、すべての子ビューについて認識し、アプリケーションイベントに基づいて表示するビューを決定する必要がありますか？サブコンポーネントにサブMVC/MVPを実装しますか？

私は中小規模の Web アプリケーションを自分で作成する初期段階にあります。「PHP Objects, Patterns, and Practice」を読み、ページ コントローラーを使用することにしました。私は PHP フレームワークに慣れておらず、複雑なフロント コントローラーを作成することは現在、プロジェクトを上回っているように思われるため、ページ コントローラーも魅力的でした。私の計画は、Web サイトのページ コントローラー バージョンをできるだけ早くリリースし、より複雑なソフトウェア設計に取り組む前に、視聴者がそれを気に入るかどうかを確認することです。

とは言っても、今後「モジュール」と開発者をさらに追加することを決定するかもしれません...その時点で、本当にフロントコントローラーに切り替える必要があります。上記の本には「ページコントローラーから始めてフロントコントローラーのパターンに移行することは不可能ではない」と書かれていますが、「不可能ではない」という言葉はかなり難しいのではないかと心配しています。

私の質問は次のとおりです。ページ コントローラーからフロント コントローラーの設計に移行するのはどれくらい「難しい」のでしょうか? ページ コントローラー ベースのアプリで作業しているときに、フロント コントローラーの設計にスムーズに移行できるコードを作成するには、どのようなことに注意すればよいですか? 理想的な状況は、コードの書き直し/再構築をできるだけ少なくし、関連するクラス/オブジェクトを使用してフロント コントローラーを追加することです。現在、私は MVC の維持にのみ注意を払っているので、経験豊富な開発者からのアドバイスは素晴らしいものです。ありがとうございました。