none
入力確認画面 RRS feed

  • 質問

  • 入力確認画面を確認したいと思っています。

    例:
    住所(ラベル)           住所の入力(テキストボックス)
    氏名(ラベル)           氏名の入力(テキストボックス)
    電話番号(ラベル)     電話番号の入力(テキストボックス)


    入力画面を作成し、入力した内容が確認したらDBに反映し確認できたことを示すことをしたいと思っています。
    このようなことをしたいのでポイントを教えていただけないでしょうか。


    tomotomody
    2009年2月10日 2:44

回答

  • ASP.NET 2.0であれば、クロスページポストバックを使われたらいかがでしょうか?

    [ASP.NET]ページ間ポストバックでポスト元ページの情報に簡単にアクセスするには?[2.0のみ、C#、VB]
    http://www.atmarkit.co.jp/fdotnet/dotnettips/409asppostback2/asppostback2.html

    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/
    • 回答としてマーク sk7474 2009年3月4日 9:59
    2009年2月10日 4:35
    モデレータ
  • 入力から最後の確認までを1ページの中でパネルの切り替えで実装してしまってもいいように思います。
    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    • 回答としてマーク sk7474 2009年3月4日 9:59
    2009年2月10日 4:51
  • MultiViewコントロールを使って、入力、確認、完了の3つを1つのaspxファイル上に記述。
    確認と完了の間でDBに格納

    http://blogs.wankuma.com/hatsune/
    • 回答としてマーク sk7474 2009年3月4日 9:59
    2009年2月10日 5:23
  •  

    必要最低限でよければ、「例」に書いてある Label, TextBox と Button を
    Form に貼り付けて、Button.Click イベントのハンドラの中で ADO.NET ラ
    イブラリを使って DB に INSERT すればできます。

    でも、それが求める答えじゃないですよね?

    • 回答としてマーク sk7474 2009年3月4日 9:59
    2009年2月10日 14:21
  •   こんにちは!(^^)!ふ~です。

    >クロスページポストバックを行おうと思います。
    これですか?
    ASP.NET]ページ間ポストバックでポスト元ページの情報に簡単にアクセスするには?[2.0のみ、C#、VB]
    http://www.atmarkit.co.jp/fdotnet/dotnettips/409asppostback2/asppostback2.html

    私の趣味では、確かに便利ですが、引き渡しが複数ある場合は、面倒な気も致します。複数手法はございます。しかし、共有エリアにはかなわないと思います。(注意:2.0では共有エリアを変更すると、ASP.NET開発サーバーの再立ち上げが必要です。)

    本題のRequiredFieldValidatorが上手く動かない理由で思いつくのは、『 「同一ページ上の複数のデーター入力フォーム」では、必ず、ValidationGroupプロパティにより、検証作業をグルーピングしておく必要がある。』と鉄則がございます。
    この辺のご検討内容がここには書かれてないようでした。

    Page.IsValid プロパティは、RequiredFieldValidatorでは効果がありません。この入力検証コントロールをフォームへ貼り付けるだけで、DHTMLの自動生成とWebサーバー側の検証を実施します。ここで、検証チェックが入りますと、ValidationGroupに属するボタンコントロールのイベントハンドラーが飛ばなくなります。ボタンハンドラー内に、if(Page.ISValid == false)return;と書いても問題は無いのですがここまで到達しません。しかし、CoustamValidatorを作成した場合は、サーバー側のCoustamValidatorイベントハンドラーで、args.IsValid=falseと設定しますと、ボタンハンドラー内の、if(Page.ISValid == false)return;を使用します。

    この辺の動作は、Webアプリケーション構築技法 赤間信幸(著) 日経BPソフトプレス ISBN978-4-89100-515-3 3800円に少しございます。以上

    2009年2月13日 5:16
  •  

    > 私の趣味では、確かに便利ですが、引き渡しが複数ある場合
    > は、面倒な気も致します。

    面倒というより、ユーザーの入力を検証して、結果 NG だった
    らユーザーに再入力を促すというケースでは、クロスページポ
    ストバックは少なくとも使うメリットはないと思いますが。

    入力画面でユーザーが入力し、終わったらクロスページポスト
    バックを使って別のページにデータを渡し、そこで検証して結
    果 NG だったらまた入力画面に戻り、エラーメッセージを表示
    して・・・というようにしますか? 普通にポストバックして
    同一ページで検証するのとどちらが良いですか?

    > 『 「同一ページ上の複数のデーター入力フォーム」では、
    > 必ず、ValidationGroupプロパティにより、検証作業をグルー
    > ピングしておく必要がある。』と鉄則がございます。

    質問者の方が最初の質問で書かれた例のような場合はその必要
    はいはずです。

    > Page.IsValid プロパティは、RequiredFieldValidatorでは
    > 効果がありません。
    > ・・・中略・・・
    > ボタンハンドラー内に、if(Page.ISValid == false)return;
    > と書いても問題は無いのですがここまで到達しません。

    そんなことはないはずですが。クライアント側で検証結果 NG
    だとポストバックがかからないだけです。クライアント側で結
    果 OK となるとポストバックがかかります。ポストバックがか
    かると、サーバー側でも検証されます(ここまで到達します)。

    ブラウザの JavaScript が無効になっているとどうなるでしょ
    うか? そういうこともあるので、クライアント側の検証はお
    まけ程度に考えておくべきだと思います。

    > しかし、CoustamValidatorを作成した場合は、サーバー側の
    > CoustamValidatorイベントハンドラーで、args.IsValid=false
    > と設定しますと、ボタンハンドラー内の、
    > if(Page.ISValid == false)return;を使用します。

    正確にはちょっと違うと思いますが。

    CoustamValidator の場合は、クライアント側の検証スクリプト
    が自動生成されないので、即ポストバックがかかってサーバー側
    での検証が始まります。

    検証結果が NG の場合 args.IsValid=false に設定(デフォルト
    は true)すると Page.IsValid が false になるということのは
    ずです。

    なお、クライアント側の検証スクリプトは、自動生成はされない
    ものの、自分で作って ClientValidationFunction に設定するこ
    とができます。そうしておけば、RequiredFieldValidator と同
    じ動き(まずクライアント側で検証、結果 OK でポストバックが
    かかってサーバー側でも検証)をします。

    • 回答としてマーク sk7474 2009年3月4日 9:58
    2009年2月13日 12:25
  •  えっと、クロスポストバックを最初に持ち出したのは私ですが(^^;、私のイメージでは、入力の検証をパスした後にクロスポストバックさせ、そこで確認画面を表示するイメージでいました。確認画面ですから、それが正しいかどうかは人間じゃなければわかりません。そこで間違っているとなると当然入力画面に返らなければなりません。そういう意味では確認画面で入力の検証を行うのもありでしょうね。どのみち確認画面から入力画面に戻る手段を実装しなければならないのですし。
    質問者の方がどのようなイメージでおられるのかを確認していないのですが、私の中では、例えば買い物をする時に住所などを入れ(この時に入力漏れなどはクライアントサイドで検証)、その後に確認画面を出して、本当にこれでよければOKを押してね、的なイメージでいました。
    別にクロスポストバックに拘っているわけではなく、普通に考えれば、入力検証後OKなら確認画面にリダイレクトすることになると思いますが、これだと入力した情報を何らかの形で確認画面に渡してあげる必要があります。これが面倒だと思ったのでクロスポストバックかなぁと思った次第です。Server.Transferを使うのはいやらしいですし。面倒といいましたが、Classic ASPではPOSTやSession変数で渡していたので、なんてことはないんですけどね。ただ、項目数が多いとちょっと大変・・・。
    そんな意味合いでパネルでの切り替えや、MultiViewという提案がされていますが、確かに保守性から言えば一つにまとまっている方が良いかもしれませんね。
    あと、確認画面をベタなHTMLで記述することはないと思いますが、確認画面はきっちりサニタイズしておかないと危ないので注意です。通常はコントロールを使うなどシステムにレンダリングさせるので問題ないと思いますが。


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/
    • 回答としてマーク sk7474 2009年3月4日 9:58
    2009年2月13日 14:16
    モデレータ
  •  

    検証して結果が NG の場合、同一ページ(入力画面)を再表示して、ユーザーに
    正しい入力を促すようなシナリオを考えていると思いますが、その場合はクロス
    ページポストバックは使うべきではありません。

    ボタンクリックで普通にポストバックして、ボタンクリックのイベントハンドラ
    で Page.IsValid プロパティで確認し、ture なら DB に INSERT して次の画面に
    進む、false なら何もせず return して入力画面を再表示するということを考え
    てください。

    • 回答としてマーク sk7474 2009年3月4日 9:58
    2009年2月12日 13:18
  • トモディー さんの発言:

    あるとき、環境は、ASP.net 2.0 で確認画面でSessionを使っているシステムもございましたが、システム上よくないのでしょうか。

    問題ありませんよ。よくやる手です。

    トモディー さんの発言:

    パネルで実装と書いてありましたが、この方法が書いてあるURLはございませんでしょうか

    検索してみました。英語ですが以下がありました。サンプルの言語ですが、一番下の方にあるリンクでC#とVBを切り替えることができます。
     
    How to use Panel Control using ASP.NET 2.0 and C#.NET http://www.aspnettutorials.com/tutorials/controls/control-panel-aspnet2-csharp.aspx
    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/
    • 回答としてマーク sk7474 2009年3月4日 9:58
    2009年2月13日 15:04
    モデレータ
  •  

    trapemiya さん>
    レスを有難うございます。

    > 私のイメージでは、入力の検証をパスした後にクロスポストバックさせ、
    > そこで確認画面を表示するイメージでいました。確認画面ですから、そ
    > れが正しいかどうかは人間じゃなければわかりません。そこで間違って
    > いるとなると当然入力画面に返らなければなりません。

    入力画面に戻るというケースがある場合、クロスページポストバックで別
    のページの確認画面に行ってしまうと、入力画面に戻るときに入力済みの
    データを再表示するなどの処置が結構面倒だと思うのですが。

    そのあたりの問題を解決するために、小野さんのレスにあったように Panel
    を使うか、初音玲さんのあったように MultiView を使うか、または Wizard
    を使うなどで、同じページ内ですべて処置したほうがよさそうに思います。
    いかがでしょう?

    • 回答としてマーク sk7474 2009年3月4日 10:00
    2009年2月14日 2:48
  • SurferOnWwwさん の発言:

    入力画面に戻るというケースがある場合、クロスページポストバックで別
    のページの確認画面に行ってしまうと、入力画面に戻るときに入力済みの
    データを再表示するなどの処置が結構面倒だと思うのですが。

    異なるWebフォーム間を遷移するわけですから、値の受け渡しは当然必要になりますね。確認画面から入力画面へクロスページポストバックした際に、確認画面の値を入力画面にセットし直さなければならない手間は確かに発生しますが、結構という形容詞が付くほどは面倒じゃない気がします。項目数にもよるんだと思いますが・・・。 

    SurferOnWwwさん の発言:

    そのあたりの問題を解決するために、小野さんのレスにあったように Panel
    を使うか、初音玲さんのあったように MultiView を使うか、または Wizard
    を使うなどで、同じページ内ですべて処置したほうがよさそうに思います。
    いかがでしょう?

    今回のトモディーさんのメール送信画面の例ですと、3つの項目なので大した手間ではないんじゃないかと思います。むしろ作りやすさや保守のしやすさで判断することになるんじゃないかと思います。例えば、確認画面でいろいろな情報を付加したりして(買い物を例に挙げると送料やポイント、納期など)、少し複雑になる場合は、確認画面を専用のWebフォームで設計した方がやりやすいように思います。反対に、入力から確認画面までが一つのWebフォームでコンポーネントのようになっている方がわかりやすいという場合もあるでしょうし、結局は、ケースバイケースでその都度判断になるのではないでしょうか?いずれにしても、ページ間の値の受け渡しの手間を無くすことは、最優先で考えることではないように思います。  
    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/
    • 回答としてマーク sk7474 2009年3月4日 10:00
    2009年2月14日 7:52
    モデレータ

すべての返信

  • ASP.NET 2.0であれば、クロスページポストバックを使われたらいかがでしょうか?

    [ASP.NET]ページ間ポストバックでポスト元ページの情報に簡単にアクセスするには?[2.0のみ、C#、VB]
    http://www.atmarkit.co.jp/fdotnet/dotnettips/409asppostback2/asppostback2.html

    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/
    • 回答としてマーク sk7474 2009年3月4日 9:59
    2009年2月10日 4:35
    モデレータ
  • 入力から最後の確認までを1ページの中でパネルの切り替えで実装してしまってもいいように思います。
    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    • 回答としてマーク sk7474 2009年3月4日 9:59
    2009年2月10日 4:51
  • MultiViewコントロールを使って、入力、確認、完了の3つを1つのaspxファイル上に記述。
    確認と完了の間でDBに格納

    http://blogs.wankuma.com/hatsune/
    • 回答としてマーク sk7474 2009年3月4日 9:59
    2009年2月10日 5:23
  •  

    必要最低限でよければ、「例」に書いてある Label, TextBox と Button を
    Form に貼り付けて、Button.Click イベントのハンドラの中で ADO.NET ラ
    イブラリを使って DB に INSERT すればできます。

    でも、それが求める答えじゃないですよね?

    • 回答としてマーク sk7474 2009年3月4日 9:59
    2009年2月10日 14:21
  • クロスページポストバックを行おうと思います。参考のURLを参考にして、同じのを作ってみました。
    確認画面ができました。

    空白チェックをさせようと思い、入力画面でRequiredFieldValidatorで空白の検証や、確認画面で空白のチェックで実装してますがなかなかうまくいきません。

    入力画面で、ユーザーコントロールをしようしているため、RequiredFieldValidatorを使うと、ユーザーコントロールでのコントロールの操作がききません。
    その他、RequiredFieldValidator以外にも、ロード時などチェックをかけてますがチェックがかかりません。


    質問のが分かりずらかったら申し訳ございません。
    よろしくお願いします。
    tomotomody
    2009年2月12日 8:51
  •  

    検証して結果が NG の場合、同一ページ(入力画面)を再表示して、ユーザーに
    正しい入力を促すようなシナリオを考えていると思いますが、その場合はクロス
    ページポストバックは使うべきではありません。

    ボタンクリックで普通にポストバックして、ボタンクリックのイベントハンドラ
    で Page.IsValid プロパティで確認し、ture なら DB に INSERT して次の画面に
    進む、false なら何もせず return して入力画面を再表示するということを考え
    てください。

    • 回答としてマーク sk7474 2009年3月4日 9:58
    2009年2月12日 13:18
  •   こんにちは!(^^)!ふ~です。

    >クロスページポストバックを行おうと思います。
    これですか?
    ASP.NET]ページ間ポストバックでポスト元ページの情報に簡単にアクセスするには?[2.0のみ、C#、VB]
    http://www.atmarkit.co.jp/fdotnet/dotnettips/409asppostback2/asppostback2.html

    私の趣味では、確かに便利ですが、引き渡しが複数ある場合は、面倒な気も致します。複数手法はございます。しかし、共有エリアにはかなわないと思います。(注意:2.0では共有エリアを変更すると、ASP.NET開発サーバーの再立ち上げが必要です。)

    本題のRequiredFieldValidatorが上手く動かない理由で思いつくのは、『 「同一ページ上の複数のデーター入力フォーム」では、必ず、ValidationGroupプロパティにより、検証作業をグルーピングしておく必要がある。』と鉄則がございます。
    この辺のご検討内容がここには書かれてないようでした。

    Page.IsValid プロパティは、RequiredFieldValidatorでは効果がありません。この入力検証コントロールをフォームへ貼り付けるだけで、DHTMLの自動生成とWebサーバー側の検証を実施します。ここで、検証チェックが入りますと、ValidationGroupに属するボタンコントロールのイベントハンドラーが飛ばなくなります。ボタンハンドラー内に、if(Page.ISValid == false)return;と書いても問題は無いのですがここまで到達しません。しかし、CoustamValidatorを作成した場合は、サーバー側のCoustamValidatorイベントハンドラーで、args.IsValid=falseと設定しますと、ボタンハンドラー内の、if(Page.ISValid == false)return;を使用します。

    この辺の動作は、Webアプリケーション構築技法 赤間信幸(著) 日経BPソフトプレス ISBN978-4-89100-515-3 3800円に少しございます。以上

    2009年2月13日 5:16
  •  

    > 私の趣味では、確かに便利ですが、引き渡しが複数ある場合
    > は、面倒な気も致します。

    面倒というより、ユーザーの入力を検証して、結果 NG だった
    らユーザーに再入力を促すというケースでは、クロスページポ
    ストバックは少なくとも使うメリットはないと思いますが。

    入力画面でユーザーが入力し、終わったらクロスページポスト
    バックを使って別のページにデータを渡し、そこで検証して結
    果 NG だったらまた入力画面に戻り、エラーメッセージを表示
    して・・・というようにしますか? 普通にポストバックして
    同一ページで検証するのとどちらが良いですか?

    > 『 「同一ページ上の複数のデーター入力フォーム」では、
    > 必ず、ValidationGroupプロパティにより、検証作業をグルー
    > ピングしておく必要がある。』と鉄則がございます。

    質問者の方が最初の質問で書かれた例のような場合はその必要
    はいはずです。

    > Page.IsValid プロパティは、RequiredFieldValidatorでは
    > 効果がありません。
    > ・・・中略・・・
    > ボタンハンドラー内に、if(Page.ISValid == false)return;
    > と書いても問題は無いのですがここまで到達しません。

    そんなことはないはずですが。クライアント側で検証結果 NG
    だとポストバックがかからないだけです。クライアント側で結
    果 OK となるとポストバックがかかります。ポストバックがか
    かると、サーバー側でも検証されます(ここまで到達します)。

    ブラウザの JavaScript が無効になっているとどうなるでしょ
    うか? そういうこともあるので、クライアント側の検証はお
    まけ程度に考えておくべきだと思います。

    > しかし、CoustamValidatorを作成した場合は、サーバー側の
    > CoustamValidatorイベントハンドラーで、args.IsValid=false
    > と設定しますと、ボタンハンドラー内の、
    > if(Page.ISValid == false)return;を使用します。

    正確にはちょっと違うと思いますが。

    CoustamValidator の場合は、クライアント側の検証スクリプト
    が自動生成されないので、即ポストバックがかかってサーバー側
    での検証が始まります。

    検証結果が NG の場合 args.IsValid=false に設定(デフォルト
    は true)すると Page.IsValid が false になるということのは
    ずです。

    なお、クライアント側の検証スクリプトは、自動生成はされない
    ものの、自分で作って ClientValidationFunction に設定するこ
    とができます。そうしておけば、RequiredFieldValidator と同
    じ動き(まずクライアント側で検証、結果 OK でポストバックが
    かかってサーバー側でも検証)をします。

    • 回答としてマーク sk7474 2009年3月4日 9:58
    2009年2月13日 12:25
  •  えっと、クロスポストバックを最初に持ち出したのは私ですが(^^;、私のイメージでは、入力の検証をパスした後にクロスポストバックさせ、そこで確認画面を表示するイメージでいました。確認画面ですから、それが正しいかどうかは人間じゃなければわかりません。そこで間違っているとなると当然入力画面に返らなければなりません。そういう意味では確認画面で入力の検証を行うのもありでしょうね。どのみち確認画面から入力画面に戻る手段を実装しなければならないのですし。
    質問者の方がどのようなイメージでおられるのかを確認していないのですが、私の中では、例えば買い物をする時に住所などを入れ(この時に入力漏れなどはクライアントサイドで検証)、その後に確認画面を出して、本当にこれでよければOKを押してね、的なイメージでいました。
    別にクロスポストバックに拘っているわけではなく、普通に考えれば、入力検証後OKなら確認画面にリダイレクトすることになると思いますが、これだと入力した情報を何らかの形で確認画面に渡してあげる必要があります。これが面倒だと思ったのでクロスポストバックかなぁと思った次第です。Server.Transferを使うのはいやらしいですし。面倒といいましたが、Classic ASPではPOSTやSession変数で渡していたので、なんてことはないんですけどね。ただ、項目数が多いとちょっと大変・・・。
    そんな意味合いでパネルでの切り替えや、MultiViewという提案がされていますが、確かに保守性から言えば一つにまとまっている方が良いかもしれませんね。
    あと、確認画面をベタなHTMLで記述することはないと思いますが、確認画面はきっちりサニタイズしておかないと危ないので注意です。通常はコントロールを使うなどシステムにレンダリングさせるので問題ないと思いますが。


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/
    • 回答としてマーク sk7474 2009年3月4日 9:58
    2009年2月13日 14:16
    モデレータ
  • たくさんのアドバイスありがとうございます。
    あるとき、環境は、ASP.net 2.0 で確認画面でSessionを使っているシステムもございましたが、システム上よくないのでしょうか。


    パネルで実装と書いてありましたが、この方法が書いてあるURLはございませんでしょうか。
    初歩的ですいません。検索してもなかなかめぼしいのがでてこないので・・・


    tomotomody
    2009年2月13日 14:48
  •  こんばんは!(^^)!ふ~です。

    説明が不足でご迷惑お掛けしております。詳しくは下記リンクで情報は十分と思われます。

    - 検証コントロールで条件付きの検証処理を行うには?
    http://www.atmarkit.co.jp/fdotnet/dotnettips/237aspcondvali/aspcondvali.html

    - 検証コントロールのパラメータを動的に設定するには?
    http://www.atmarkit.co.jp/fdotnet/dotnettips/240aspdynavali/aspdynavali.html

    - CustomValidatorコントロールでマスタ重複チェックを実装するには?
    http://www.atmarkit.co.jp/fdotnet/dotnettips/244aspcustvali/aspcustvali.html

    - 複数のボタンが存在するフォーム上で検証コントロールを利用するには?
    http://www.atmarkit.co.jp/fdotnet/dotnettips/251aspdisablevalid/aspdisablevalid.html

    - CustomValidatorコントロールでクライアント検証を有効にするには?
    http://www.atmarkit.co.jp/fdotnet/dotnettips/279aspcustvali/aspcustvali.html

    - 検証コントロールのエラー・メッセージを一元管理するには?
    http://www.atmarkit.co.jp/fdotnet/dotnettips/292pagevalidate1/pagevalidate1.html

    - アプリケーション共通の処理をPage派生クラスで実装するには?
    http://www.atmarkit.co.jp/fdotnet/dotnettips/295pagevalidate2/pagevalidate2.html

    - 複数のボタンを持つフォームで検証コントロールを利用するには?
    http://www.atmarkit.co.jp/fdotnet/dotnettips/415aspvalidgroup/aspvalidgroup.html

    これは、クロスページポストバックでもとのページに戻る場合に必要な情報です。
    10 行でズバリ !! Web アプリケーションの画面遷移 (C#)
    http://msdn.microsoft.com/ja-jp/events/dd282859.aspx

    これで、私は、成功間違いなしと思っております。ご活躍を期待しております。
    2009年2月13日 14:54
  • トモディー さんの発言:

    あるとき、環境は、ASP.net 2.0 で確認画面でSessionを使っているシステムもございましたが、システム上よくないのでしょうか。

    問題ありませんよ。よくやる手です。

    トモディー さんの発言:

    パネルで実装と書いてありましたが、この方法が書いてあるURLはございませんでしょうか

    検索してみました。英語ですが以下がありました。サンプルの言語ですが、一番下の方にあるリンクでC#とVBを切り替えることができます。
     
    How to use Panel Control using ASP.NET 2.0 and C#.NET http://www.aspnettutorials.com/tutorials/controls/control-panel-aspnet2-csharp.aspx
    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/
    • 回答としてマーク sk7474 2009年3月4日 9:58
    2009年2月13日 15:04
    モデレータ
  • 学習もかねて、メール送信ですが、
    http://tomotomody.ddo.jp/Mail/HM_MailSendInput.aspx


    の確認画面を作成しました。
    とりあえずSessionで保持することにしました。
    tomotomody
    2009年2月13日 19:42
  •  

    trapemiya さん>
    レスを有難うございます。

    > 私のイメージでは、入力の検証をパスした後にクロスポストバックさせ、
    > そこで確認画面を表示するイメージでいました。確認画面ですから、そ
    > れが正しいかどうかは人間じゃなければわかりません。そこで間違って
    > いるとなると当然入力画面に返らなければなりません。

    入力画面に戻るというケースがある場合、クロスページポストバックで別
    のページの確認画面に行ってしまうと、入力画面に戻るときに入力済みの
    データを再表示するなどの処置が結構面倒だと思うのですが。

    そのあたりの問題を解決するために、小野さんのレスにあったように Panel
    を使うか、初音玲さんのあったように MultiView を使うか、または Wizard
    を使うなどで、同じページ内ですべて処置したほうがよさそうに思います。
    いかがでしょう?

    • 回答としてマーク sk7474 2009年3月4日 10:00
    2009年2月14日 2:48
  •  

    トモディーさん>

    > 学習もかねて、メール送信ですが、
    > http://tomotomody.ddo.jp/Mail/HM_MailSendInput.aspx
    > の確認画面を作成しました。

    一番最初の質問と話がぜんぜん違うように見えます。

    何にせよこれにて一件落着で、最初の話は忘れてよくて、このスレッドはクローズで
    いいのでしょうか?

    2009年2月14日 2:59
  • SurferOnWwwさん の発言:

    入力画面に戻るというケースがある場合、クロスページポストバックで別
    のページの確認画面に行ってしまうと、入力画面に戻るときに入力済みの
    データを再表示するなどの処置が結構面倒だと思うのですが。

    異なるWebフォーム間を遷移するわけですから、値の受け渡しは当然必要になりますね。確認画面から入力画面へクロスページポストバックした際に、確認画面の値を入力画面にセットし直さなければならない手間は確かに発生しますが、結構という形容詞が付くほどは面倒じゃない気がします。項目数にもよるんだと思いますが・・・。 

    SurferOnWwwさん の発言:

    そのあたりの問題を解決するために、小野さんのレスにあったように Panel
    を使うか、初音玲さんのあったように MultiView を使うか、または Wizard
    を使うなどで、同じページ内ですべて処置したほうがよさそうに思います。
    いかがでしょう?

    今回のトモディーさんのメール送信画面の例ですと、3つの項目なので大した手間ではないんじゃないかと思います。むしろ作りやすさや保守のしやすさで判断することになるんじゃないかと思います。例えば、確認画面でいろいろな情報を付加したりして(買い物を例に挙げると送料やポイント、納期など)、少し複雑になる場合は、確認画面を専用のWebフォームで設計した方がやりやすいように思います。反対に、入力から確認画面までが一つのWebフォームでコンポーネントのようになっている方がわかりやすいという場合もあるでしょうし、結局は、ケースバイケースでその都度判断になるのではないでしょうか?いずれにしても、ページ間の値の受け渡しの手間を無くすことは、最優先で考えることではないように思います。  
    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/
    • 回答としてマーク sk7474 2009年3月4日 10:00
    2009年2月14日 7:52
    モデレータ
  •  SurferOnWwwさん、コメントありがとうございます。
    正直この学習したやり方は、あまり自分としては好きじゃありませんが、とりあえずは一件落着しました。

    最初に、質問した内容と違っていますが、あくまで確認画面を表示させたかっただけなのでメール送信画面にしました。
    説明不足ですいません。
    最初の質問の通り、現在別のサイトで作成しています。


    又、皆さんのたくさんのアドバイスありがとうございました。

    自分の足りないところなどさまざまな勉強になりました。
    ありがとうございます。

    tomotomody
    2009年2月14日 15:44
  •  

    trapemiya さん>

    レスを有難うございました。


    > 確認画面から入力画面へクロスページポストバックした際に、確認画面の値を
    > 入力画面にセットし直さなければならない手間は確かに発生しますが、結構と
    > う形容詞が付くほどは面倒じゃない気がします。項目数にもよるんだと思いま
    > すが・・・。 

    自分的には、例えば Session を使うとすると、入力画面で Session キーの設定、
    確認画面で null かどうかの判定 → null だった場合の処置、入力画面に差し
    戻された場合も同様に null かどうかの判定 → null だった場合の処置、すべ
    て完了したときのキーの削除など、たとえ1項目でも面倒だと感じます。同一ペ
    ージで処置すればそれらは必要ないので特にそう感じます。

    ただ、「結構」という形容詞が適切であるか否かは、個人的な主観によると思い
    ますので、それは取り消させていただきます。不適切と感じられたら失礼しまし
    た。

    > 結局は、ケースバイケースでその都度判断になるのではないでしょうか?
    > いずれにしても、ページ間の値の受け渡しの手間を無くすことは、最優先で考
    > えることではないように思います。

    それはその通りだともいます。

    でも、今回のようなケースは、どう考えても Wizard 等を使って同一ページです
    べて処置する方が良いと思います。

    でも、まぁ、これも個人的な好みの問題にすぎないのかもしれません。Wizard
    を使って他の面でかえって面倒になっては本末転倒ですし、トモディーさんの例
    ではブラウザの[戻る]ボタンに依存しているようですし・・・

    2009年2月15日 2:58
  • こんにちは。中川俊輔 です。

    皆様、沢山の回答ありがとうございます。

    トモディーさん、フォーラムのご利用ありがとうございます。
    勝手ながら、有用な情報と思われる回答へ回答マークをつけさせていただきました。

    今後ともフォーラムをよろしくお願いします。
    それでは!

    マイクロソフト株式会社 フォーラム オペレータ 中川 俊輔
    2009年3月4日 10:02