6

特定のフォームは複雑すぎて 1 ページに収まりません。たとえば、マップ上の場所の選択、カレンダー ウィジェットでのイベントのスケジューリング、以前の入力に応じてフォームの特定の部分の変更など、フォームに大量の構造化データが含まれる場合、特定のフォームを複数のページに分割します。

これは、動的な Web ページと Javascript で簡単に実行できます。異なるページを持つタブ ウィジェットを作成するだけで、実際に送信されたフォームにはタブ ウィジェット全体とそのすべての入力フィールドが含まれ、POST操作全体に対する単一の要求が生成されます。 .

ただし、特定の入力フィールドを生成するのに時間がかかる場合があります。ページが生成された後でも計算負荷が高くなり、ローエンドのコンピューター ユーザーのブラウザーに負担がかかることさえあります。さらに、以前の入力に基づいて適応するフォームを作成することが困難または不可能になります。

したがって、特定のフォームを複数のフル ページ リクエストに分割する必要があります。

特に、フォームの最初のページがにリダイレクトされ、クライアントから要求されるPOSTため、これは難しいことがわかります。保存されたフォーム データを からに渡すのが難しいところです。/location/a/location/bGETPOST /location/aGET /location/b

Spring Web Flow (主に依存性注入機能で知られる Spring フレームワークのサブプロジェクト) の作成者である Erwin Vervaet は、かつて、このフレームワークでのこの機能を示すブログ記事を書き、同様の機能を実装した Lift Web フレームワークと比較しました。. その後、彼は他の Web フレームワークへの挑戦を提示します。これについては、後の記事で詳しく説明します。

特にステートレスな REST ベースの性質を考えると、Yesod はこの問題にどのように直面するのでしょうか?

4

1 に答える 1

3

まず、これに対する事前構築済みのソリューションはまだ存在していません (少なくとも私は知っています)。そして、言及されている他のフレームワークがどのように問題を解決するかについてはよく知りません。したがって、ここで述べていることはほとんど推測にすぎません。しかし、それが機能することはかなり確信しています。

ここでの問題の核心は、ページ A の POST パラメーターをページ B の GET 要求にエンコードすることです。これを行う最も簡単な方法は、ページ A の POST パラメーターをセッション変数に貼り付けることです。ただし、そうするとナビゲーションが完全に壊れてしまいます。説明したように戻る/進むはまったく機能しません。

REST に戻ります。POST パラメーターをリクエスト自体にエンコードする必要があります。これは、要求されたパスまたはクエリ文字列に情報を入れることを意味します。そして、クエリ文字列がおそらく最も理にかなっています。

未加工の POST パラメーターをクエリ文字列に入れることには懸念があります。これにより、プロキシ サーバーがコンテンツを簡単に詮索できるようになるからです。したがって、clientsession の既存の暗号化を活用したいと思います。つまり、以前のフォーム送信の署名付き暗号化バージョンをクエリ文字列パラメーターに貼り付けます。

もう少し具体的にするには：

  • ユーザーは GET 経由でページ A に移動します。
  • ユーザーがページ A を POST 経由で送信します。
  • サーバーはフォームの送信を検証し、値を取得してシリアル化し、暗号化/ハッシュします。
  • ユーザーは、ページ A からの暗号化/ハッシュ化された値を含むクエリ文字列パラメーターを使用して、GET としてページ B にリダイレクトされます。
  • このプロセスを必要な回数だけ続けます。
  • 最後のページでは、クエリ文字列パラメーターを復号化し、すべてのフォーム送信を取得できます。

これは、誰かが興味を持っているなら、書くのが楽しいアドオン パッケージになりそうです。

于 2012-07-23T02:41:27.700 に答える