アーカイブ
Update 2 そして その先の話
TechEd North America 2014 がはじまりました。
ここ でセッションが見れるようになってくるかと。
で、VS2013 の Update 2 も発表になりました。
○Update 2 の概要
Visual Studio 2013 Update 2 is here!
○ASP.NET 関係の Update 2 での変更点
Announcing new Web Features in Visual Studio 2013 Update 2 RTM
ここまではまあ予想のうち。
で、.NET Framework に関して、この先の話まで発表されてます。
○VisualStudio に関する発表の全体像
The Next Generation of .NET – ASP.NET vNext
ASP.NET vNext に関しては、 Scott Hanselman の Blog が詳しいです。
というか、この Blog をみて何ができるようになるのかやっとわかりました。
とうとう IIS から切り離された形で ASP.NET が動き出す、んですね。
そか、ASP.NET は中でコンパイラはしってたから Roslyn が必要だった、、、んか？
とか、いろいろ考えるとこはあります。
まだ「次」はいつなのかはっきりしませんが、こんなセカイが近づいていると思うとわくわくしますね。
Identity 2.0 の有用な情報かな？
すみません、自分でまとめたんじゃありません（ｗ
ASP.NET MVC and Identity 2.0: Understanding the Basics
ASP.NET Identity 2.0: Setting Up Account Validation and Two-Factor Authorization
基本的な情報と実際に使うために必要な設定情報とかがまとめられているようです。
自分としては outlook.com をつかったメールの送信方法のサンプルがうれしかったり（ｗ
だいぶ変わったけど、しっかり「使える」ものになっていると感じます。
まずは空のプロジェクトつくって
PM> Install-Package Microsoft.AspNet.Identity.Samples –Pre
とやって、サンプルプログラムを動かしてみるのがよいかと。
ただ、このサンプル、結構コード量が多いんですよね。
Update 2 では Identity 2.0 がテンプレートに入ってくるんだと思うけど、どこまでの機能を持たせたものになるのかなぁ。。。
最新の GridView なら、、、の裏側
間があいてしまいましたが。
前回の記事でほのめかしておいた、ItemType プロパティを設定したときになにが起きてるのか、というあたりをちょっとのぞいてみましょう。
まず、GridView の AutoGenerateCollumns プロパティを false にして、BoundField コントロールとして ID、Name、Mail の各項目を追加します。
こんな感じになります。
で、実行して動作を確認すると、、、
こんな動きをします。
ItemType を追加した直後とちょっとちがいますね？
さて、BoundField コントロールをすべて DynamicField コントロールに置き換えましょう。
これで動かすと、
はい、ItemType を追加したときと同じ動きになりました。
これでわかりますかね？
ItemType を設定する前は GridView の内部では BoundField コントロールが使われていて、ItemType を追加すると、DynamicField コントロールが使われるんですね。
GridView の内部で使われるコントロールが変化するあたりは ASP.NET 4 で追加された EnableDynamicData 拡張メソッドを利用したときと一緒です。
というか、拡張メソッドを利用するのはちょっと面倒だったんですが、ItemType プロパティを設定するだけで動くようになった、というのが正しいんですかね？
DynamicField コントロールは検証コントロールまで自動的に追加してくれるのでクライアント側の検証が動作するんですね。
クライアント側の検証では「控えめなバリデーション」が使われるようになったのは 4.5 からなんですが、そのあたりは kiyokura さんの Blog のこの記事で確認してもらうのがよいかな？
DynamicField コントロールについては別にもう少し掘り下げてみようかと思います。
というか、ちょっと面白い動きしたはずなんですが、いま確認とってないので確認でき次第まとめる、ということで。
DynamicField コントロール面白いんですけどね。
いかんせん、情報がないですよね。
EnableDynamicData 拡張メソッドの話も、日本語だと私の Blog の記事とナオキ君が CodeZine に書いた記事ぐらいしか見つからないし。。。
あ、ひとつ注意点を。
DynamicField コントロールを明示的に記述して使うとき、ItemType プロパティの設定を削除するとエラーになります。
VSUG Day でのセッションを聞かれた方は覚えてるかもしれませんが、最後のほうで DynamicField コントロール使おうとしてエラーになって動かなかったのはこのせいでした。
ItemType プロパティのからみで、もうひとつ。
ItemType プロパティを設定しなくてもモデルバインディングは動きます。
それは前回の記事の動作で確認できますよね。
このモデルバインディング、ASP.NET MVC のように汎用的に使えるといろいろと面白いんですが、WebForms ではどうやら特定のコントロールでのみ使えるような感じです。
このあたりもきちんと調べてみないと。。。
というところで、今回の記事はここまで。
次は、、、モデルバインディングの話が先になるかな？
最新の GridView なら検証の設定も楽々！
※この記事は One ASP.NET Advent Calender の21日分のエントリーです。
21日分、、、
前の記事では GridView の SelectMethod プロパティを設定してデータの抽出を行いました。
データの更新には UpdateMethod を利用します。
GridView に UpdateMethod と AutoGenerateEditButton プロパティの設定を追加します。
UpdateMember メソッドの実装はこんな感じです。
ASP.NET MVC を使ったことのある人にはわかりやすいですね。
UpdateMember メソッドは Member 型の引数をとっていますが、これはモデルバインダーという仕組みが今回 WebForms にも採用されているからできることです。
モデルバインダーはブラウザからのリクエストであがってきたデータを、モデル（上記の場合は Member）のプロパティ名と照らし合わせて、自動的に Member 型のインスタンスを生成してくれます。
データの追加の部分は EntityFramework の最近のバージョン（4.2からじゃなかったかな？）ではこういう記述でデータの追加ができます。
デバッグの実行を開始すると編集リンクが追加されていて、データの編集が可能になっています。
Name を「おの2」としてデータが更新できることを確認してみましょう。
さて、ここから今日の本題。
以前の GridView では、データの更新時に検証を行おうとすると、データのフィールドをテンプレートフィールドにして、そこに検証コントロールを一つ一つ貼っていかないといけない、というかなり手間のかかるものでした。
それが、今なら。。。
まず、GridView のすぐ下あたりにエラー時のメッセージを表示するために ValidationSummary を貼り付けます。
Member クラスの Name プロパティに Required 属性を追加します。
Name を必須の入力項目にするわけですね。
Member クラスは EDM を作り直したら上書きされますので、そのような操作を行うときは注意しましょう。
まぁ、どんな属性を設定したか覚えておけばいいだけの話です。
そして UpdateMember メソッドをちょっと修正します。
このあたり、ASP.NET MVC と同様ですね。
で、デバッグ実行して Name を空にして更新しようとすると、
このように、きちんと必須チェックを行ってくれるようになります。
モデルバインダーが Member のインスタンスを生成する際、設定されている属性によるチェックも自動的に実施してくれて、エラーの状態まで登録してくれるのでこのようになるんですね。
エラーの状態はプログラムで追加することもできます。
こんなふうに ModelState にエラー状態を追加すると、どんな場合でも更新できなくなります。
まあ、ふつうは独自の更新チェックの条件を追加する場合に使うんですけどね。
ここまででも便利は便利なのですが、もうひとつ。
GridView の ItemType プロパティに Member クラスを設定します。
そうすると、
さっきのすべての更新をエラーにするプログラムを修正していないのに、必須入力の検証が行われて、またそのチェックが実行された項目に「*」が表示されています。
これ、HTMLをみるとわかりますがクライアント側でスクリプトによる検証が行われているんですね。
ItemType プロパティを設定することで何が起きてるのか。。。
という話を続けるには記事がながくなりすぎたので、それは次の機会にしたいと思います。
しかし、GridView、かなり使えるやつになってると思いません？
環境が許すならどんどん使っていきたいですね。
最新の GridView ならページングもソーティングも楽々！
この記事は One ASP.NET Advent Calender の20日のエントリーです
GridView は便利なんですけど、ページングやソーティングをしっかり実装しようとするとなかなか手ごわいですよね。
データ量が限られてるのがわかってるなら SqlDataSource でさくっと動かしてもいいんですけど、のちのち問題になるのわかりきってますしねぇ。。。
と、面倒だった実装が最新（4.5）版の GridView なら楽々です。
ということでとにかく動かしてみましょう。
さて、まずは新しい Web サイトで ASP.NET Web フォームサイトを作って DB を追加します。
DB じゃなくてもいけるはずですが、明日もこの環境使うために DB で。
そして WebForms で CodeFirst で簡単に DbContext 作る方法がわかってないので DB First で Entity Framework 使っていきたいと思います。
＃ASP.NET MVC なら POCO のクラス書くだけであとはスキャッフォールディングにおまかせで DbContext 作ってくれるんですけどね。。。
と、気を取り直して DB 作成。
そそ、この新しいテーブルデザイン画面いいですよね。
なにがいいって IDENTITY の設定がワンクリックでできること。
最初は項目表示されてないので右クリックして表示項目を追加してあげるひつようがありますが。
あと、CREATE 文もぱっと目に入ってくるので SQL の勉強にもいいですよね。
つい保存ボタン押したくなっちゃうんですが、専用の「更新」メニューをクリックして DB つか Member テーブル作成、っと。
で、GridView でページングとソーティングの話ですから適当にデータつっこんでおきましょう。
さて、DB First ですから次は EDM 追加します。
もうデフォルト設定のままウィザードたたいて突っ走ってしまいますよ、と。。。
はい、できました、っと。
なんかセキュリティの警告でますけど、T4テンプレートでソース生成するときって出るみたいです。
なぜか連続2回。
まぁ、とにかく EDM できたけどタブに[*]ついてるので一回ビルド走らせておきます。
で、今回かなり優秀になってるな、と思ったのが
へんな名前空間とかなしで、Member クラスを生成してくれます。
これなら使い勝手いいですよね。
と、GridView はどうしたんだ、といわれそうなので新規でWebページを追加します。
で、いきなりコードを表示させて次のようなデータを呼び出してくるメソッドを追加します。
と、ここで待望の GridView です。
GridView を Web ページに追加して SelectMethod プロパティにさっき書いたメソッドを設定してあげましょう。
はい、ここでとりあえずデバッグ実行してみましょうか。
さくっとデータ拾ってきてますね。
では、本題のページングとソーティング。
プロパティの設定を3つ追加しました。
で、実行すると。。。
あらあら、エラーです。
でも、このエラーきちんと見ておいてくださいね。
LINQ に慣れてる人ならもうなんとなくわかるかも。
で、OrderBy つけろ、と言われているのでデータ取り出すとこにデフォルトのソート順設定しましょう。
ま、こんなとこでしょうか。
さて、デバッグ実行っと。
はい、ページングとソーティングのリンクが追加されました。
2ページめは、、、
ちゃんと表示されますね。
Name をクリックすると、、、
ソートした状態でのページングもOK、っと。
ソーティングの昇順降順もきちんと保持しているようで、同じソートリンクを何回もクリックするとそのたびに昇順降順が入れ替わります。
いやー、ここまでコード何行書きました？
いままでのあの苦労はなんだったんだろう、と思いません？
で、ちょっとだけ裏側を解説すると、さっきでたエラーで メソッド Skip を GridView が使ってるのがわかります。
Skip、Take は LINQ 使ってページングするときの定番ですよね。
SelectMethod で IQueryable を返しているので、そこに Skip、Take がのせられてデータをとってきてるんだろう、という推測ができます。
なら、ソーティングは当然 OrderBy が使われてるんだろうな、と。
LINQ は遅延実行されるので、実際に DB から取り出されるのは Skip、Take で指定された必要なデータのみ。
なので、ViewState の肥大化なんて気にすることなく安心して利用することができますね。
と、とりあえず今日はここまで。
明日は GridView 使ううえでやっぱり面倒だった検証関係をとりあげます。
そだ、最後にひとつ。
わかりやすいので GridView を例にあげてますけど、ほかのデータ操作系のコントロール、DetailsView、FormView、ListView、ListView でもこれ使えますからね。
便利になりますねぇ。。。
どっとねっとふぁん 