トップ回答者
入力確認画面

質問
回答
-
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
-
こんにちは!(^^)!ふ~です。
>クロスページポストバックを行おうと思います。
これですか?
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円に少しございます。以上 -
> 私の趣味では、確かに便利ですが、引き渡しが複数ある場合
> は、面倒な気も致します。面倒というより、ユーザーの入力を検証して、結果 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
-
えっと、クロスポストバックを最初に持ち出したのは私ですが(^^;、私のイメージでは、入力の検証をパスした後にクロスポストバックさせ、そこで確認画面を表示するイメージでいました。確認画面ですから、それが正しいかどうかは人間じゃなければわかりません。そこで間違っているとなると当然入力画面に返らなければなりません。そういう意味では確認画面で入力の検証を行うのもありでしょうね。どのみち確認画面から入力画面に戻る手段を実装しなければならないのですし。
質問者の方がどのようなイメージでおられるのかを確認していないのですが、私の中では、例えば買い物をする時に住所などを入れ(この時に入力漏れなどはクライアントサイドで検証)、その後に確認画面を出して、本当にこれでよければOKを押してね、的なイメージでいました。
別にクロスポストバックに拘っているわけではなく、普通に考えれば、入力検証後OKなら確認画面にリダイレクトすることになると思いますが、これだと入力した情報を何らかの形で確認画面に渡してあげる必要があります。これが面倒だと思ったのでクロスポストバックかなぁと思った次第です。Server.Transferを使うのはいやらしいですし。面倒といいましたが、Classic ASPではPOSTやSession変数で渡していたので、なんてことはないんですけどね。ただ、項目数が多いとちょっと大変・・・。
そんな意味合いでパネルでの切り替えや、MultiViewという提案がされていますが、確かに保守性から言えば一つにまとまっている方が良いかもしれませんね。
あと、確認画面をベタなHTMLで記述することはないと思いますが、確認画面はきっちりサニタイズしておかないと危ないので注意です。通常はコントロールを使うなどシステムにレンダリングさせるので問題ないと思いますが。
★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/- 回答としてマーク sk7474 2009年3月4日 9:58
-
-
トモディー さんの発言:問題ありませんよ。よくやる手です。
あるとき、環境は、ASP.net 2.0 で確認画面でSessionを使っているシステムもございましたが、システム上よくないのでしょうか。
トモディー さんの発言:検索してみました。英語ですが以下がありました。サンプルの言語ですが、一番下の方にあるリンクでC#とVBを切り替えることができます。パネルで実装と書いてありましたが、この方法が書いてあるURLはございませんでしょうか
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
-
trapemiya さん>
レスを有難うございます。> 私のイメージでは、入力の検証をパスした後にクロスポストバックさせ、
> そこで確認画面を表示するイメージでいました。確認画面ですから、そ
> れが正しいかどうかは人間じゃなければわかりません。そこで間違って
> いるとなると当然入力画面に返らなければなりません。入力画面に戻るというケースがある場合、クロスページポストバックで別
のページの確認画面に行ってしまうと、入力画面に戻るときに入力済みの
データを再表示するなどの処置が結構面倒だと思うのですが。そのあたりの問題を解決するために、小野さんのレスにあったように Panel
を使うか、初音玲さんのあったように MultiView を使うか、または Wizard
を使うなどで、同じページ内ですべて処置したほうがよさそうに思います。
いかがでしょう?- 回答としてマーク sk7474 2009年3月4日 10:00
-
SurferOnWwwさん の発言:異なるWebフォーム間を遷移するわけですから、値の受け渡しは当然必要になりますね。確認画面から入力画面へクロスページポストバックした際に、確認画面の値を入力画面にセットし直さなければならない手間は確かに発生しますが、結構という形容詞が付くほどは面倒じゃない気がします。項目数にもよるんだと思いますが・・・。
入力画面に戻るというケースがある場合、クロスページポストバックで別
のページの確認画面に行ってしまうと、入力画面に戻るときに入力済みの
データを再表示するなどの処置が結構面倒だと思うのですが。
SurferOnWwwさん の発言:今回のトモディーさんのメール送信画面の例ですと、3つの項目なので大した手間ではないんじゃないかと思います。むしろ作りやすさや保守のしやすさで判断することになるんじゃないかと思います。例えば、確認画面でいろいろな情報を付加したりして(買い物を例に挙げると送料やポイント、納期など)、少し複雑になる場合は、確認画面を専用のWebフォームで設計した方がやりやすいように思います。反対に、入力から確認画面までが一つのWebフォームでコンポーネントのようになっている方がわかりやすいという場合もあるでしょうし、結局は、ケースバイケースでその都度判断になるのではないでしょうか?いずれにしても、ページ間の値の受け渡しの手間を無くすことは、最優先で考えることではないように思います。そのあたりの問題を解決するために、小野さんのレスにあったように Panel
を使うか、初音玲さんのあったように MultiView を使うか、または Wizard
を使うなどで、同じページ内ですべて処置したほうがよさそうに思います。
いかがでしょう?
★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/- 回答としてマーク sk7474 2009年3月4日 10:00
すべての返信
-
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
-
クロスページポストバックを行おうと思います。参考のURLを参考にして、同じのを作ってみました。
確認画面ができました。
空白チェックをさせようと思い、入力画面でRequiredFieldValidatorで空白の検証や、確認画面で空白のチェックで実装してますがなかなかうまくいきません。
入力画面で、ユーザーコントロールをしようしているため、RequiredFieldValidatorを使うと、ユーザーコントロールでのコントロールの操作がききません。
その他、RequiredFieldValidator以外にも、ロード時などチェックをかけてますがチェックがかかりません。
質問のが分かりずらかったら申し訳ございません。
よろしくお願いします。
tomotomody -
-
こんにちは!(^^)!ふ~です。
>クロスページポストバックを行おうと思います。
これですか?
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円に少しございます。以上 -
> 私の趣味では、確かに便利ですが、引き渡しが複数ある場合
> は、面倒な気も致します。面倒というより、ユーザーの入力を検証して、結果 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
-
えっと、クロスポストバックを最初に持ち出したのは私ですが(^^;、私のイメージでは、入力の検証をパスした後にクロスポストバックさせ、そこで確認画面を表示するイメージでいました。確認画面ですから、それが正しいかどうかは人間じゃなければわかりません。そこで間違っているとなると当然入力画面に返らなければなりません。そういう意味では確認画面で入力の検証を行うのもありでしょうね。どのみち確認画面から入力画面に戻る手段を実装しなければならないのですし。
質問者の方がどのようなイメージでおられるのかを確認していないのですが、私の中では、例えば買い物をする時に住所などを入れ(この時に入力漏れなどはクライアントサイドで検証)、その後に確認画面を出して、本当にこれでよければOKを押してね、的なイメージでいました。
別にクロスポストバックに拘っているわけではなく、普通に考えれば、入力検証後OKなら確認画面にリダイレクトすることになると思いますが、これだと入力した情報を何らかの形で確認画面に渡してあげる必要があります。これが面倒だと思ったのでクロスポストバックかなぁと思った次第です。Server.Transferを使うのはいやらしいですし。面倒といいましたが、Classic ASPではPOSTやSession変数で渡していたので、なんてことはないんですけどね。ただ、項目数が多いとちょっと大変・・・。
そんな意味合いでパネルでの切り替えや、MultiViewという提案がされていますが、確かに保守性から言えば一つにまとまっている方が良いかもしれませんね。
あと、確認画面をベタなHTMLで記述することはないと思いますが、確認画面はきっちりサニタイズしておかないと危ないので注意です。通常はコントロールを使うなどシステムにレンダリングさせるので問題ないと思いますが。
★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/- 回答としてマーク sk7474 2009年3月4日 9:58
-
こんばんは!(^^)!ふ~です。
説明が不足でご迷惑お掛けしております。詳しくは下記リンクで情報は十分と思われます。
- 検証コントロールで条件付きの検証処理を行うには?
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 -
トモディー さんの発言:問題ありませんよ。よくやる手です。
あるとき、環境は、ASP.net 2.0 で確認画面でSessionを使っているシステムもございましたが、システム上よくないのでしょうか。
トモディー さんの発言:検索してみました。英語ですが以下がありました。サンプルの言語ですが、一番下の方にあるリンクでC#とVBを切り替えることができます。パネルで実装と書いてありましたが、この方法が書いてあるURLはございませんでしょうか
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
-
学習もかねて、メール送信ですが、
http://tomotomody.ddo.jp/Mail/HM_MailSendInput.aspx
の確認画面を作成しました。
とりあえずSessionで保持することにしました。
tomotomody -
trapemiya さん>
レスを有難うございます。> 私のイメージでは、入力の検証をパスした後にクロスポストバックさせ、
> そこで確認画面を表示するイメージでいました。確認画面ですから、そ
> れが正しいかどうかは人間じゃなければわかりません。そこで間違って
> いるとなると当然入力画面に返らなければなりません。入力画面に戻るというケースがある場合、クロスページポストバックで別
のページの確認画面に行ってしまうと、入力画面に戻るときに入力済みの
データを再表示するなどの処置が結構面倒だと思うのですが。そのあたりの問題を解決するために、小野さんのレスにあったように Panel
を使うか、初音玲さんのあったように MultiView を使うか、または Wizard
を使うなどで、同じページ内ですべて処置したほうがよさそうに思います。
いかがでしょう?- 回答としてマーク sk7474 2009年3月4日 10:00
-
トモディーさん>
> 学習もかねて、メール送信ですが、
> http://tomotomody.ddo.jp/Mail/HM_MailSendInput.aspx
> の確認画面を作成しました。一番最初の質問と話がぜんぜん違うように見えます。
何にせよこれにて一件落着で、最初の話は忘れてよくて、このスレッドはクローズで
いいのでしょうか? -
SurferOnWwwさん の発言:異なるWebフォーム間を遷移するわけですから、値の受け渡しは当然必要になりますね。確認画面から入力画面へクロスページポストバックした際に、確認画面の値を入力画面にセットし直さなければならない手間は確かに発生しますが、結構という形容詞が付くほどは面倒じゃない気がします。項目数にもよるんだと思いますが・・・。
入力画面に戻るというケースがある場合、クロスページポストバックで別
のページの確認画面に行ってしまうと、入力画面に戻るときに入力済みの
データを再表示するなどの処置が結構面倒だと思うのですが。
SurferOnWwwさん の発言:今回のトモディーさんのメール送信画面の例ですと、3つの項目なので大した手間ではないんじゃないかと思います。むしろ作りやすさや保守のしやすさで判断することになるんじゃないかと思います。例えば、確認画面でいろいろな情報を付加したりして(買い物を例に挙げると送料やポイント、納期など)、少し複雑になる場合は、確認画面を専用のWebフォームで設計した方がやりやすいように思います。反対に、入力から確認画面までが一つのWebフォームでコンポーネントのようになっている方がわかりやすいという場合もあるでしょうし、結局は、ケースバイケースでその都度判断になるのではないでしょうか?いずれにしても、ページ間の値の受け渡しの手間を無くすことは、最優先で考えることではないように思います。そのあたりの問題を解決するために、小野さんのレスにあったように Panel
を使うか、初音玲さんのあったように MultiView を使うか、または Wizard
を使うなどで、同じページ内ですべて処置したほうがよさそうに思います。
いかがでしょう?
★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/- 回答としてマーク sk7474 2009年3月4日 10:00
-
trapemiya さん>
レスを有難うございました。
> 確認画面から入力画面へクロスページポストバックした際に、確認画面の値を
> 入力画面にセットし直さなければならない手間は確かに発生しますが、結構と
> う形容詞が付くほどは面倒じゃない気がします。項目数にもよるんだと思いま
> すが・・・。自分的には、例えば Session を使うとすると、入力画面で Session キーの設定、
確認画面で null かどうかの判定 → null だった場合の処置、入力画面に差し
戻された場合も同様に null かどうかの判定 → null だった場合の処置、すべ
て完了したときのキーの削除など、たとえ1項目でも面倒だと感じます。同一ペ
ージで処置すればそれらは必要ないので特にそう感じます。ただ、「結構」という形容詞が適切であるか否かは、個人的な主観によると思い
ますので、それは取り消させていただきます。不適切と感じられたら失礼しまし
た。> 結局は、ケースバイケースでその都度判断になるのではないでしょうか?
> いずれにしても、ページ間の値の受け渡しの手間を無くすことは、最優先で考
> えることではないように思います。それはその通りだともいます。
でも、今回のようなケースは、どう考えても Wizard 等を使って同一ページです
べて処置する方が良いと思います。でも、まぁ、これも個人的な好みの問題にすぎないのかもしれません。Wizard
を使って他の面でかえって面倒になっては本末転倒ですし、トモディーさんの例
ではブラウザの[戻る]ボタンに依存しているようですし・・・