1

Zend Framework (PHP) を中心に大まかに形成された非常に悪いコードベースで開発しているため、ORM は使用できず、他のフレームワークも使用できません。Zend_Form を使用してみましたが、ドキュメントがまばらすぎることがわかりました (Zend_Form で小さなフォームを作成しましたが、このサイズのものはありませんでした)。

長いフォーム (6 ページ) を作成する必要があります。ユーザーは、フォームを送信しようとするまで、検証なしで、各ステップを好きなように切り替えることができます (私の意見では良い考えではありませんが、それは仕様に記載されていることです)。

プロセスの最後に、フォームが検証され、データがデータベース内のいくつかの異なるテーブルに分割されます。面白いことに、このフォームには 3 つのバージョンがあり、すべてフィールドがわずかに変更されていますが、大きな変更はありません。それらはすべて同じテーブルにデータを格納します。

それで、これを行うための最良の方法は何ですか？どのように構造化すればよいですか? また、そのようなフォームを作成する必要がある場合はどうしますか? 私はこれを PHP で書いていますが、他の言語のプログラマーからの反応も聞きたいです。また、そのようなフォームを作成するためのライブラリやツールがあれば、それも聞きたいです。

4

3 に答える 3

1

ZFを使用してこれを行ったことはなく、最後のステップを送信するときにのみ検証を行うフォームを作成したことも、ユーザーが必要に応じてステップからステップにジャンプできるマルチステップフォームを作成したこともありません(たとえば、最初のステップから4番目にジャンプすることを意味します)。

私が行ったのは 5 ステップのフォームです (4 番目のステップ内にさらに 3 つのサブステップが存在する可能性があります)。ユーザーは、一度に 1 ステップずつ手順を実行するか、一度に 1 ステップずつ戻ることができます。各ステップが送信され、検証されます。有効になるまで、ユーザーは次のステップにジャンプできませんが、戻ることはできます。挿入された値はセッション内に保存されます。モデル (他のサブクラスを含む構造化クラス) を作成したので、各ステップが送信されて有効になった後、セッション内に保存されるこのモデルにデータが設定されます。

ユーザーが必要に応じてステップをジャンプできる非常に大きなフォームが必要な場合は、次の 2 つの方法を検討します。

  1. ステップを視覚的にタブに分割したフォームを 1 つだけ作成します。各タブには関連するフィールドのみが含まれ、最後のタブのみに送信ボタンが含まれます。他のタブには、次のタブのみを開く「次へ」ボタンが含まれます。フィールドの数に問題がある可能性があります。POST で送信できるフィールドの数は限られていますが、GET ではさらに限られた数のフィールドしか送信できません (申し訳ありませんが、数値はわかりません)。次に、送信が呼び出された後、検証が行われ、DB テーブルを埋めることができます...
  2. ステップごとにフォームを作成します。データを格納するモデルを作成します。各ステップは送信し、そのモデルにデータのみを保存します (最後のステップを除く - これは挿入されたデータの検証も呼び出します) - モデルはセッション内に保存されます。検証が失敗した場合 ユーザーを最初の無効なステップにリダイレクトし、データが無効なステップでメッセージを表示します (また、そのステップを視覚的に無効にします)。検証に問題がなければ、モデルを取得して DB テーブルに入力します...

私は ZF を使用してそのようなことをしたことがないので、両方の方法がどれほど難しいかはわかりません...そして、決してそうする必要がないことを願っています.

また、クライアントと話すことを検討し、最後のステップでのみ検証するのはちょっとばかげており、ユーザーフレンドリーではないことを説明します...

于 2012-05-28T13:17:56.533 に答える
0

ORMまたはフレームワークを使用できないという制限があるため、シリアル化とオブジェクトのセッションオブジェクトとしての格納を確認できます。

フォームに固有のいくつかのプロパティを使用して「フォーム」クラスを作成し、各フォーム送信後にこれらの値を設定します。

于 2012-05-28T13:18:42.680 に答える
0

いくつかのセクションに分割します。

フォーム処理

ここでは主に 2 つの選択肢があります (いずれにしても強い感情はありません)。

  1. フォーム全体を 1 ページに作成し、JavaScript (または jQuery などのライブラリ) を使用してフォーム セクション間を移動します。オプションで、ここでもクライアント側の検証を行うことができます。

  2. ページごとに 1 つのフォームを作成し、セッションを使用するか、非表示の入力フィールドを使用してすべてをフォーム内に保持することにより、PHP にキャリーオーバーを処理させます (個人的にはセッションの方が好きです)。

わずかなバリエーションの処理は、最初のページでバージョンを渡すだけで実行でき、戦略パターンを採用することでそれに応じてフォームを変更できます。

最終提出

検証には、PHP のfilter拡張機能を使用できます (デフォルトで同梱されています)。それはかなりまともで拡張可能です。

検証が失敗した場合は、最初のエラーのみを表示するのではなく、すべてのエラーを収集してユーザーに表示することをお勧めします (おそらく、それぞれのセクションにジャンプするためのハイパーリンクを使用します)。各セクションで、使いやすくするためにエラーを再度言及する場合があります (ユーザーは前後にジャンプすることを嫌います)。

フォーム全体をデータベースに保存することは、フォーム自体を表示することと、バリエーションの点でそれほど違いはありません。ここでも戦略パターンを使用します。

これで大部分がカバーされることを願っています。改善できると思われる場合はお知らせください。

于 2012-05-28T13:16:08.763 に答える