2009-04-08 18 views
0

私はかなり長いHTMLフォームをユーザーが埋めています。記入した後、ユーザーは提出しているデータのプレビューを受け取ります。そこから、彼らはシステムにデータをコミットするか、または戻って編集することができます。私はこのプレビューステップを処理するための最良のアプローチが何であるか疑問に思っています。私が持っていたいくつかのアイデアがあります:フォームプレビューで送信

  • ストア プレビュー
  • ストア セッション
  • でフォームデータが ステータス欄を示すと、DBにデータを置くためのクッキーでフォームデータそれは プレビュー

このようなプレビューを作成するときに通常何をしますか?考慮すべき他の問題はありますか?

答えて

3

隠しフィールド()としてデータを入れます。

なぜクッキーやセッションはありませんか? - ユーザーがこのデータを破棄すると、他のページに移動することができます。彼が後で戻ってデータをそのまま見ると、彼はおそらく驚いた。

なぜデータベースではありませんか? - ユーザーがブラウザを閉じるだけで、データベースのデータをクリーンアップする場合...私はむしろこれのためのcronの仕事を書いていないでしょう。

1

ベストプラクティスかどうかは分かりませんが、私がこのタスクを実行したときにセッションに入れました。私は、セッションが私のために十分であったので、ユーザーがただ一つのセッションの間にデータをプレビューし、提出/再編集することを期待しました。

ユーザーのマシンにプレビューする場合は、Cookieを使用する必要があります。つまり、ユーザーはセッション中にプレビューを吟味したり編集したりする必要はありませんが、この操作と次のセッションでプレビューに戻ります。このaproachを使用すると、ユーザーはブラウザでCookieを拒否できると考える必要があります。そういうわけで、人々は通常、セッションをクッキーと一緒に組み合わせます。

プレビューと編集操作を何らかの形で追跡して保存する必要がない場合は、ステータス列を使用してデータベースにデータを配置する必要はありません。データベースをテーブルの引き出しとして想像することができます。保管しておきたいものを後で見つけることができます。プレビュードラフトを描画するだけで、結果が送信された後は、最終バージョンのみがドロワ/データベースに保存され、プレビューはデータベースに入れないよりもむしろぶら下げられます。しかし、何らかの理由で後でドラフトを通過すると思われる場合は、データベースに格納する必要があります。

は、私はそれが私の英語とは明らかだかどうかわからないんだけど、私は自分のベストを尽くした:D

+0

DBについての良い点は、後で使用しない限り、そこにプレビューデータを保存する必要はないようです。 –

0

私は、フォームが最初の場所で記入することだったいかに難しいかに基づいて、それを評価したいです。それが長いプロセス(住宅ローンなどの情報など)で、ユーザーログインをしている場合は、未完了のフォームを保存して後で戻ってくる機会をユーザーに提供したい場合があります。

セッションは、(設定に応じて)1時間未満かかる作業にのみ適しています。簡単に始めることができ、仕上げが簡単なデータの手動入力(CD/DVDカタログ作成など)は、セッションを保存するのに最適です。同様に、人がいくつかの書類を停止して根絶しなければならない場合(再び、モーゲージアプリやオンライン税務フォームなどの場合)、セッションがタイムアウトすると本当に怒っている人がいるでしょう。情報を再入力する必要があります。

データが後続のリクエストに渡され、基本セッション機能に既にアクセスしているため、Cookieに直接コンテンツを挿入しないでください。

はアクセスをタイムスタンプする必要があります(「My 2008 Mortgage Documents」のようなユーザーの判断で保存された名前を使用しないでください)。後でそれを掃除することができます。ユーザーが途中で保存した場合は、フォームを完了するか削除するまで放置してください。

関連する問題