ラベル ASP.NET MVC の投稿を表示しています。 すべての投稿を表示
ラベル ASP.NET MVC の投稿を表示しています。 すべての投稿を表示

2010年12月18日土曜日

Razor Helper的なForEachでテンプレート

今年も終わりですね。タイトル意味分かんないですね。

来週から夏休み&年末年始休暇に入るので、今年の仕事終了です。てへ。ブログサイトがあるのをすっかり忘れるくらい追い込まれる毎日。よくもまぁ、こんな状態が続くもんだと感心するばかりです。え?きれてねーよ。

そんなことはいいんですけどね、ちょっとここ見てみてくださいよ。

Razor, Nested Layouts and Redefined Sections - Marcin On ASP.NET - Site Home - MSDN Blogs

ナイスエントリーにも程があるデスヨ。

Layout用のビューを直接指している、子供ビューのセクションはみえるけど、多段Layoutになってて孫ビューのセクションはスコープの範囲外でエラーになっちゃうっていうエントリー。

実際に試してみたらたしかに動かない。Section not defined。そ

foreach

りゃそうだ。それを克服するために中間LayoutでRedefineSectionで孫のセクションを生成(WebPageBase.DefineSection)してしまおうよっていう強引さには度肝を抜かれますがなによりそこじゃないんです。

その部分より何よりセクション初期値をヘルパーに渡す部分ですよ!

Func<object, HelperResult> defaultContent

これを知っておくと何が出来るかというと...

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
}
@helper ForEach(IEnumerable<int> values, Func<object, HelperResult> template){
    var partialHtml = new System.Text.StringBuilder();
    foreach(var value in values){
        partialHtml.Append( template(value));
    }

    Write(MvcHtmlString.Create(partialHtml.ToString()));
}
<div>
<ul>
@ForEach(Enumerable.Range(1,5),
    @<li>@item</li>
)
</ul>
</div>

↑こんなコード書けるってことですよ。ヘルパーにRazor構文のテンプレートを渡してるんですよ。いいでしょ?ん~、もんどりうつ。

追記:もっと簡単でよかった。

@helper ForEach(IEnumerable<int> items, Func<object, HelperResult> template){
    foreach(var item in items){
        Write(template(item));
    }
}

@helperだとGenericメソッドに出来なさそうなので、もうちょっと調べてみたら、普通に@functionsで実装するサンプルをAndrew君が...。

VibrantCode - Inside Razor - Part 3 – Templates

この場合は↓こうね。

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
}
@functions{
    static IHtmlString ForEachGeneric<T>(IEnumerable<T> items, Func<T, HelperResult> template)
    {
        var sb = new System.Text.StringBuilder();
        foreach(var item in items){
            sb.Append(template(item));
        }
        
        return MvcHtmlString.Create(sb.ToString());
    }
}

<div>
<ul>
@(ForEachGeneric<int>(Enumerable.Range(1,5),
    @<li>@item</li>
))
</ul>
</div>

 

foreach2

小っちゃ!
クリックして拡大してみてね。

Razorのコンパイル結果を見てみると分かるけど、ヘルパーに渡すテンプレートブロックにはobject型のitemが必ずわたりまする。

2010年10月24日日曜日

MVC 3 Betaのステップイン

前回のエントリーでも行ったように、デバッグ時にソースにステップインできると便利ですよね。ソースサーバーに上がってるならそっちのほうが手軽だけど。

とりあえず、ASP.NET MVC3 Betaのソースにステップインしてみましょう!

aspnet - Release: ASP.NET MVC 3 Beta

stepin1

ソースのダウンロードをしたら、まずは新規プロジェクトの作成。

stepin2

stepin3

とにかく作る。何も考えずにクリック・クリック。そしたら↓こうなりますね。

stepin4

ここからです!

参照設定から、

  • System.Web.Mvc
  • System.Web.Helper
  • System.Web.WebPages

の3つを削除。男らしくね。乙女らしくでもいい。

stepin5

つづいて、ソリューションにダウンロードしたMVCのソースからプロジェクトを追加。既存プロジェクトの追加ですね。

結構沢山必要です。

  • mvc3-beta-source\
    • mvc3\
      • src\
        • SystemWebMvc\System.Web.Mvc.csproj
    • webpages\
      • src\
        • System.Web.Helpers\System.Web.Helpers.csproj
        • System.Web.Razor\System.Web.Razor.csproj
        • System.Web.WebPages\System.Web.WebPages.csproj
        • System.Web.WebPages.Razor\System.Web.WebPages.Razor.csproj
        • WebMatrix.Data\WebMatrix.Data.csproj

stepin6

あとは、アプリケーションプロジェクトで削除した参照設定の分をここで追加。

stepin7

ほらね、これでReSharperも黙った。

stepin8

最後の一手が必要なんだけど、この段階でステップインしてみましょう。とりあえず、RazorViewのRenderViewを開いてブレークポイント。F5を押してみる。

stepin9

残念ながら例外ラッシュ。

stepin10

stepin11

最後の一手を打つ時が来ました。

エラー内容の通り、デフォルトのweb.configだとGACのアセンブリを見るようになってるので、ちゃんとローカルのアセンブリを見るよう変更する必要があります。

アプリケーションルートのweb.configのassembliesセクションを以下のように。

<compilation debug="true" targetFramework="4.0">
  <assemblies>
    <add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
    <add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
    <!--<add assembly="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
    <add assembly="WebMatrix.Data, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
    <add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
    <add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />-->
    <add assembly="System.Web.Mvc" />
    <add assembly="WebMatrix.Data" />
    <add assembly="System.Web.WebPages" />
    <add assembly="System.Web.Helpers" />
  </assemblies>
</compilation>

~/Views/web.configも同じようにGAC見ないように変更。

<configSections>
  <!--<sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
    <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
    <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
  </sectionGroup>-->
  <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor">
    <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor" requirePermission="false" />
    <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor" requirePermission="false" />
  </sectionGroup>
</configSections>

<system.web.webPages.razor>
  <!--<host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />-->
  <host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc" />
  <pages pageBaseType="System.Web.Mvc.WebViewPage">
    <namespaces>
      <add namespace="System.Web.Mvc" />
      <add namespace="System.Web.Mvc.Ajax" />
      <add namespace="System.Web.Mvc.Html" />
      <add namespace="System.Web.Routing" />
    </namespaces>
  </pages>
</system.web.webPages.razor>

いずれも、VersionとCultureとPublicTokenを消すだけね。そうすると...。

stepin12

stepin13

ヒャッホーイ!ステップインするし、ちゃんと動くね!

※ホントはfavicon.icoのnot foundの例外が起きててちょっとウザイけど。

これで何か気になるところがあると何でも調べられて便利この上ないですな。WebPage.InitializePageなんていうvirtualな空メソッドがいて、必ず初期化時に呼び出されてたりするなんてのもみえてきて、ココでも処理の横取りできるな~とか。ワクワクすっぞ。

ちなみに”_ViewStart.cshtml”があるから初期化処理なんかはココに書くんだけど(ギャフン)、RazorViewEngine.ViewStartFileNameにinternal static readonlyでセットされてる。

スクリーンショット祭りだね...。

2010年10月23日土曜日

RazorのLayout

MVC 3 Betaのソースが公開されましたね!凄いリファクタリングが進んでます。WebMatrix namespaceのソース(MVC関係なくWebPageとして)も含まれてるし、マニアにはたまらないですね!

aspnet - Release: ASP.NET MVC 3 Beta

Databaseや各種Helperなんかはドキュメント整理また無くてもすべてまるっとお見通しだ!な状態で使っていけるのは嬉しい限りです。

Scottguのブログで以下のようなエントリがありました。

ASP.NET MVC 3: Layouts with Razor - ScottGu's Blog

WebFormsでいうところの.MasterはWebPagesでLayoutというのですが(基底クラスの違うcshtml/vbhtmlですね)、どうやって使いましょうかという内容です。@RenderBody(他にもSectionとかいいものもたくさんありますよ!)が魔法の言葉です。

まず、簡単にIndex.htmlにLayoutプロパティを指定する方法。これは直感的で分かりやすいですね。対象となるViewのヘッダ部で直書きですから。

で、全部のViewにいちいちLayout書くの面倒だ!ってなった場合、StartPageクラスの隠しViewとして_ViewStart.cshtml(~/Viewsに置いとくとよしなに処理してくれる優れものだけど、規約嫌いの人には気持ち悪いと言われそう)というのがあるので、それを使って一括で指定してしまう方法があります。

ここまでをScottguは紹介してくれてますが、MVCerならだれもが気になるところのViewメソッドのMaster指定オーバーロードの場合どうなるんだべ?というところ。

public ActionResult Index(string name, string country)
{
  ViewModel.Message = "Welcome to ASP.NET MVC!";

  return View();
}

↑これが普通だけど、↓こうするパターンです。

public ActionResult Index(string name, string country)
{
  ViewModel.Message = "Welcome to ASP.NET MVC!";

  return View("Index","_Layout");
}

部分的にLayoutを変更したい時などによく使いますが、StartPageで指定したものと、WebPage内で指定したもの、ViewResultで指定したものの優先順位が気になりますよね!

ね?

試してみましょう。まずは_ViewStart.cshtmlとIndex.cshtmlの両方でLayoutを指定した場合どちらが優先されるのか。比較するために以下のような単純な_SimpleLayout.cshtmlと_PinkLayout.cshtmlを~/Views/Shared直下に置いておきます。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>@View.Title</title>
</head>
<body>
    <h1>Simple Layout</h1>
    <div>
        @RenderBody()
    </div>
</body>
</html>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>@View.Title</title>
</head>
<body style="background-color:pink;">
    <h1>Pink Layout</h1>    
    <div>
        @RenderBody()
    </div>
</body>
</html>

 

この状態で、_ViewStart.cshtmlでは"_Layout.cshtml"を指定し、Index.cshtmlでは"_SimpleLayout.cshtml"を指定してみる。

結果は↓こうです。

layout1

Index.cshtmlに指定したLayoutが優先されますね。

この状態で、ControllerでPinkLayoutを指定してみます。

public ActionResult Index(string name, string country)
{
  ViewModel.Message = "Welcome to ASP.NET MVC!";

  return View("Index", "_PinkLayout");
}

layout2

おぉ~。Controller指定(ViewResult)最強の優先順位。理由は公開されたソースを見ていくとわかるんでしょうね。なんか深くてみるの面倒だな~。見てみるか。えと...。

RazorViewEngineからWebViewPageへ潜って、RazorViewへさかのぼるとLayoutPathをOverridenLayoutPathにセットしてますね。WebPageBaseにLayoutを保持し、WebViewPageにOverridenLayoutPathを保持するという2段構え。RazorViewのコンストラクタでControllerで指定するLayoutパスをRazorViewのLayoutPathに保持して、その値をWebViewPageのOverridenLayoutPathにさらにセットすることで、Razor単体でのLauout設定(_ViewStart.cshtmlとIndex.cshtmlでのLayout)を無視して適用できるようにするってことですね。いつ無視するのかというとWebViewPageのExecutePageHierarchyでしょうか。WebPageBase.Layoutプロパティを!String.IsNullOrEmpty(OverridenLayoutPath)の時に上書いてます。

Razorテンプレートがコンパイルされた時点で、Layoutプロパティの値をセットするというコードが生成されてるけど、それを実行時(Execute実行後)に上書くことでControllerからLayoutを指定できるようになっているという仕組みということですね。

ベースクラスのExecutePageHierarchyを実行後(WebPageBase.ExecutePageHierarchy内部でExecuteを呼び出します)、OverridenLayoutPathを上書きです。

#pragma checksum "…\Views\Home\Index.cshtml" "{406ea660-64cf-4c82-b6f0-42d48172a799}" "AE4546615BCDE09DA34E6447CC0AFD71"
//------------------------------------------------------------------------------
// <auto-generated>
//     このコードはツールによって生成されました。
//     ランタイム バージョン:4.0.30319.1
//
//     このファイルへの変更は、以下の状況下で不正な動作の原因になったり、
//     コードが再生成されるときに損失したりします。
// </auto-generated>
//------------------------------------------------------------------------------

namespace ASP {
    using System;
    using System.Collections.Generic;
    using System.IO;
    using System.Linq;
    using System.Net;
    using System.Web;
    using System.Web.Helpers;
    using System.Web.Security;
    using System.Web.UI;
    using System.Web.WebPages;
    using System.Web.Mvc.Ajax;
    using System.Web.Mvc;
    using System.Web.Mvc.Html;
    using System.Web.Routing;
    
    
    public class Index_cshtml : System.Web.Mvc.WebViewPage {
        
        protected ASP.global_asax ApplicationInstance {
            get {
                return ((ASP.global_asax)(Context.ApplicationInstance));
            }
        }
        
        public override void Execute() {

            
            #line 1 "C:\Users\takehara\Documents\My SkyDrive\Develop\MySamples\Mvc3bApplication1\Mvc3bApplication1\Views\Home\Index.cshtml"
  
    Layout = "~/Views/Shared/_SimpleLayout.cshtml";
    View.Title = "Home Page";


            
            #line default
            #line hidden
WriteLiteral("\r\n<h2>");


            
            #line 6 "C:\Users\takehara\Documents\My SkyDrive\Develop\MySamples\Mvc3bApplication1\Mvc3bApplication1\Views\Home\Index.cshtml"
Write(View.Message);

            
            #line default
            #line hidden
WriteLiteral("</h2>\r\n<p>\r\n    To learn more about ASP.NET MVC visit <a href=\"http://asp.net/mvc" +
"\" title=\"ASP.NET MVC Website\">http://asp.net/mvc</a>.\r\n</p>\r\n</script>");


        }
    }
}

 

ん?なんか違う気がしてきた。BuildManagerから出力されたコードだと、Execute内でLayoutセットしてるよね...。おやや~?モヤモヤする。まぁ、いっか。また今度調べてみよう。

追記

で、ちょっと調べたらPageContextっていうのがいた。Push/Popで積んでいく感じで実行するんだけど、これがなにかするくさい。普通に指定されたLayoutを実行したあとにOverridenLayoutPathを実行するのか、実行そのものを置き換えるのか。今度はそこか。Layoutの状態で実行した後、OverridenLayoutPathで実行?そんな無駄な動きするかな~。

しょうがないのでステップ実行。

layout4

RenderView.ExecutePageHierarchyでWebPageBase.ExecutePageHierarchyを実行。ここでStartPageを登録しているので_ViewStart.Executeを実行。続いてChildPage(WebViewPage)として登録されているIndex.cshtmlのExecutePageHierarchyを実行。この時の出力をスタックに積んでいるStringWriterに置き換える(もとはHttpWriter)。で、Index.cshtmlの引数なしWebPageBase.ExecutePageHierarchyを実行(深い)。この中からIndex.cshtmlのExecuteがやっと実行される。このExecuteがRazorテンプレートの出力結果でoverrideされてる実体ですね。なので、ここでページ単位でのLayout指定が実行されます。ちなみにこの段階ではまだ_Layout.cshtmlは実行されてないですね。

ここでやっとOverridenLayoutPathの登場。自身のLayoutをこの値で上書き。WebPageBase.ExecutePageHierarchyに戻ってPopContext()。誰やねん!これが重要で、この中でStringWriterに書き出したRazorのExecute結果を退避。やっとLayoutの実体が見えてきた。

layout3

RenderSurroundingに退避したコンテンツの実体と、Layoutを渡してます。この中で@RenderBodyにコンテンツの実体を埋め込んでレスポンスに流れていくということでした。長い...。

と、言うわけで、Index.cshtmlを実行後、対象となるLayoutをOverridenLayoutPath(Controllerで指定)を優先で取り出し、結果的に_PinkLayout.cshtmlが実行されるというわけですね。スッキリ!

WebPageExecutingBaseに階層がコメントとして残されてます。この辺はソースを見ることの特権ですね。流石のクオリティです。

/*
WebPage class hierarchy

WebPageExecutingBase      The base class for all Plan9 files (_pagestart, _appstart, and regular pages)
    AppStartBase          Used for _appstart.cshtml
    WebPageRenderingBase
        PageStartBase     Used for _pagestart.cshtml
        WebPageBase
            WebPage       Plan9Pages
            ViewWebPage?  MVC Views
*/

2010年9月1日水曜日

TFS on CodePlex

CodePlexにBoFのデモで使用したお絵描きアプリ「MVC Graffiti」をアップロードしました。SkyDriveに上げたならこっちには必要ないじゃないかと思われるところですが、オープンソースとして公開しておくといろいろとお得な特典が待ち受けています。

例えば、Visual StudioのIDE内で利用出来るSVNクライアント、VisualSVNなんかもその一つで、オープンソースを公開していれば無料でライセンスを貰えます。貰いました。てへ。他にReSharperなんかもオープンソースオーナーにはもらえるみたいですよね。MVPじゃなくてもオープンソースを公開してるとライセンスをもらえるツール類はいろいろあるものです。とりあえず今狙ってるのはdotTrace。V4出るみたいだしね!

dotTrace Profiler :: Frequently Asked Questions

これまでSubversion、Mercurialと使ってみたので今回はTFSで。その手順を書いておきます。

codeplex1 codeplex2codeplex3 codeplex4codeplex5 codeplex6

http://www.codeplex.comにアクセスして、上記の通り順番に。ここまでは何の変哲もない操作です。英語ですけど気にせずチャレンジしちゃいましょう!

codeplex7

で、ソースタブを確認してみると、なんかダメなんよ的なメッセージ。しばらくしないとダメなのかな?と、思って一晩寝かせてみても変わらずアクセス出来ません表示のままです。

こりゃいかんじゃないですか。なので、早速CodePlexにコンタクト。

CodePlex - Contact Us

やっぱり英語なんですけど、あんまり気にせず適当な英語でアクセス出来ないことをアピール。返事が来るまで気長に待ちましょう。今回は週末を挟んだので2日くらいで返事が来ました。

This issue has been resolved. Your project should be successfully created.

Sorry for the inconvenience,
Matt

こんな感じで返事が来たので、早速VS2010からアクセス!

tfs1

一度ソースタブに行ってみると、↑こんな感じで設定方法を見ることが出来ます。

ここスルーするとあとでログインできなくて悲しいことになります。画像をズームすると分かるんですが、CodePlexのアカウントと、TFSのアカウントは別モンで”takepara”でCodePlexにログインするならTFSには”snd\takepara_cp”となります。snd\と_cpを忘れるとずっと怒られ続けます。

これに従って、TFSサーバーをチームエクスプローラに追加。

tfs2

ソリューションをソース管理に追加して出来上がり!

tfs3

なんですが、このままだとVS2010起動してTFSにアクセスするたびにログインを要求されてしまいます。切ないですね。面倒ですね。鬱陶しいことこのうえない!チームじゃなくてひとりだから文句いわれるのか??

tfs9

tfs4

そういうわけじゃないみたいで、ちゃんと対応方法がありました。

まずはコントロールパネルのユーザーアカウントで「資格情報マネージャ」を開いてみましょう(こんな機能があるのを初めて知りました)。そこには過去アクセスしたことのあるないようが記憶されてました。ここにCodePlexの設定も追加します。

tfs5

「Windows資格情報の追加」をクリックして資格情報を追加します。

tfs6

ここで気をつけないとイケないのがsnd\と_cp。忘れずに!これを登録しておくとVS2010を起動するたびにログイン要求されることもなくなり、とても優雅な開発を味わうことができるようになります。

tfs7

ちなみにTFS使ったことないです。チェックアウトとか意識しなくてもいいらしいとは聞いたんですが、ソリューションエクスプローラに鍵マークでてるとドキドキします...。普通に開いて編集できるんだけど、SVNになれてるとなんか気になる。

そんなこんなで、画像ばっかりで中身の薄っぺらいエントリーですが、個人利用リポジトリとしてのCodePlex利用+オープンソースコミッター特典狙いで、気楽にソースを公開してみてはどうでしょうか。

2010年8月19日木曜日

MVC HTML5 Toolkit を MVC3 Preview1のRazorで使う

ASP.net MVC HTML5 Helpers Toolkit

ナオキさんに勧められたので調べてみました。

ナオキにASP.NET(仮) : MVC HTML5 Toolkit が CodePlex にて公開!

mvchtml5

まずは、上記サイトからソースとAssemblyをダウンロードしてみました。名前空間がSystem.Web.Mvc.Html5というところがムフフなポイントですね。

ソースがあまりにもシンプルで短いので見てみるのをお勧めします。で、見てみてサンプルを動かしてみました。

面白いね~。3大派手機能のうちVideo/Audioのタグには対応。あとはCanvasも同じように作ればいいね!

ベースとなるHtml5TextBoxとHtml5RangeNumberはModelStateを取り出してないから、値がバインドしてこないです。ちょっと残念。InputHelperを使ってるHtml5TextBoxForHelperはViewData.ModelState.TryGetValueでちゃんとバインドしてるから、いろいろ試しながら作ってるのか、意図的にバインドしないようにしてる感じです。input type="range"もバインドしてくれていいと思うけどな~。せっかくhtmlHelper.GetModelStateValueも用意してるんだし。

サンプルのMVCプロジェクトではSite.MasterでDOCTYPE htmlの出力じゃないけど、そんなの気にせずSafari,Chromeはちゃんとレンダリングしてくれるのがすばらしい。

Dean Hume - ASP.net MVC HTML5 Toolkit

ちなみにMVC2用だとうたってますが、そんなの気にせずMVC 3 Preview1で使ってみましょう。作者のサイトに書かれてる通り、参照設定に追加して、Global.asaxにおまじない。

mvchtml5_2

もちろんRazorなので、NamespaceをWebPageからHtmlHelperへの拡張メソッドが参照できるように、Global.asaxに以下のように追記。

protected void Application_Start()
{
  AreaRegistration.RegisterAllAreas();
  CodeGeneratorSettings.AddGlobalImport("System.Web.Mvc.Html5");

  RegisterGlobalFilters(GlobalFilters.Filters);
  RegisterRoutes(RouteTable.Routes);
}

ページに直接usingとして書いてもいいですが、すべてのページに書くのは馬鹿らしいじゃないですか。Tumblrにも書いたと思いますが、Preview1ではWeb.configのsystem.web/pages/namespacesはみてくれないです。そこはRTMまでには解決されることでしょう。

前回作ったサルベージ用アプリに追加してみる。

@using(Html.BeginForm("Index","Home",FormMethod.Get)) {

  @Html.TextBox("q")

  <input type="submit" value="検索" />

  @Html.Html5Range(1, 100 , 0, 23, null).AsHtml()
}

AsHtml拡張メソッドもがある前提です。

対応してるChromeだと↓こんな感じでちゃんとRangeコントローラが出てきます。

mvchtml5_3

Firefoxだとまだ対応してないので、type属性無視してTextboxがそのまま表示されます。

mvchtml5_4

お手軽でとてもいいじゃないですか!これは楽しい!

あと、個人的に面白いと思うのが↓。

aspnet - Release: Sprite and Image Optimization Framework

地味な感じがするけど、ASP.NETらしさ爆発じゃないですかね~。

2010年7月18日日曜日

Programming Microsoft ASP.NET MVC

Amazon.co.jp: Programming Microsoft ASP.NET MVC: Dino Esposito: 洋書

先月6/3にこの本が届いてから、毎日通勤電車で少しずつだけど読み進め、やっと終わることが出来たっす。時間かかり過ぎ。

ASP.NET MVC 2に関する書籍は発売延期を繰り返しまだ全然出てきてないですが、7/21にはAmazon.co.jp: Pro ASP.NET MVC 2 Framework, Second Edition: Steven Sanderson: 洋書も届くので、その前に読み終えることができてちょっとホッとしてます。

3部構成になっていて、1部はMVCとはなんぞや、2部は内部構造、3部は機能紹介と結構豊富でAppendix含め全549ページ。読み応え抜群です。

1部のMVC、MVP、MVVPのアーキテクチャデザインの解説はかなり勉強になります。Original MVCとModel 2のMVCの違い、ASP.NET MVCはModel2なのでレイヤ的にModelはView Modelなんだよ、だったり(ヘルプ - IBM WebSphere Help Systemを見てもわかるとおりMVC Model 2でのModelとビジネスロジック+DALは別物)。Chapter 3は何度読んでも面白いです。それ以外のASP.NETとIISの関係なんかは知ってる人には面白味にかける部分かも。2部以降少し新鮮味に欠ける部分も多くなりますが、明確に書かれているのを見たことがないMVC1とMVC2の機能の違い(全然知らなかったのがTempDataの変化)がところどころ差し込まれてるので、これまた面白いです。3部のChapter 11はカスタマイズポイントが事細かに書かれているので、個人的には一番盛り上がりました。ValueProviderはあんまり取り上げられてなくてちょっと残念。というか、Providerに関してはそれほどかも。

Chapter2のNote枠に書かれてたことで、なぬ~と思ったところがあったので紹介しておくと「.NET4では直ってるけど、system.WebServer/handlersにUrlRouting.axdが無いとIIS7の統合モードで動かないバグがあるよ」っていうところ。ローカルIISにデプロイして確認してみたところ、404エラーが出てちゃんと機能させることが出来ませんでした。気をつけようね!

なんだかんだと、面白いことがたくさん書かれてて、読んで損することは絶対ないと言い切れる内容だと思います。英語でDinoさんの難しい言い回しの部分は多々あるけど、その辺は適当に辞書引いて関係ないと思ったら読み飛ばし、気になるところだけがっつり読み込む感じで十分楽しめます!

次の本は776ページらしいので、またのんびり2カ月くらいかけて読んみようと思います。

2010年7月6日火曜日

DeserializingModelBinder

モダンチョキチョキズを知ってるのはどのくらい少数派なのかが気になる今日この頃。

ASP.NET MVC 2 Futuresに含まれているHtml.SerializeとDeserializeAttributeをクラスのプロパティに対して適用するのにお悩みな方へ。DeserializeModelBinder自体がなぜかDeserializeAttributeクラスのprivate sealedクラスと定義されてしまっているので、全く同じものを以下のように定義することで、ModelBinderAttributeを指定して比較的簡単に出来るようです。

  public class DeserializingModelBinder : IModelBinder
  {

    private readonly SerializationMode _mode;

    public DeserializingModelBinder() : this(SerializationMode.Plaintext) { }
    public DeserializingModelBinder(SerializationMode mode)
    {
      _mode = mode;
    }

    public object BindModel(ControllerContext controllerContext, 
ModelBindingContext bindingContext) { if (bindingContext == null) { throw new ArgumentNullException("bindingContext"); } var vpResult = bindingContext.ValueProvider
.GetValue(bindingContext.ModelName); if (vpResult == null) { // nothing found return null; } MvcSerializer serializer = new MvcSerializer(); string serializedValue = (string)vpResult.ConvertTo(typeof(string)); return serializer.Deserialize(serializedValue, _mode); } }

↑これはソースからコピペです。MvcSerializerが使えなかったらどうしようかと思いましたが、こちらは平気ですね。

  public class Division
  {
    public string Name { get; set; }
    public Person Boss { get; set; }
    public People People { get; set; }
  }

  [Serializable]
  [ModelBinder(typeof(DeserializingModelBinder))]
  public class People : List<Person>
  {}

  [Serializable]
  public class Person
  {
    public string Name { get; set; }
    public DateTime MemorialDay { get; set; }
  }

↑このようなモデルクラスたちを定義してみました。あえてPeopleクラスを定義しているのはModelBinderAttributeがプロパティに指定できないからです。DeserializeAttributeにいたってはParameterにしか指定できないし、ModelMetadataProviderらへンに手を入れる必要がある気がしなくもなく(たぶんメタデータを見てModelBinderを切り替えるような仕組みでしょうか)、難しそうだったので使っていません。

このようにクラスを定義した上で、ModelBinderAttributeでModelBinderを指定する方法が比較的簡単でスマート(?)じゃないかと思います。こうしておくとアクションでは何も意識する必要なく以下のようにアクションパラメータを生成してくれるようになります。

  public ActionResult Division()
  {
    var model = new Division
    {
      Name = "ブチャラティチーム",
      Boss = new Person { Name = "ブローノ・ブチャラティ", 
MemorialDay = new DateTime(2010, 1, 1) }, People = new People { new Person {Name = "ジョルノ・ジョバァーナ",
MemorialDay = new DateTime(2010, 2, 1)}, new Person {Name = "レオーネ・アバッキオ",
MemorialDay = new DateTime(2010, 3, 1)}, new Person {Name = "グイード・ミスタ",
MemorialDay = new DateTime(2010, 4, 1)}, new Person {Name = "ナランチャ・ギルガ",
MemorialDay = new DateTime(2010, 5, 1)}, new Person {Name = "パンナコッタ・フーゴ",
MemorialDay = new DateTime(2010, 6, 1)} } }; return View(model); } [HttpPost] public ActionResult Division(Division model) { return View(model); }

Viewは以下のようにシンプルです。

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<MvcApplication1.Models.Division>" %>
<%@ Import Namespace="Microsoft.Web.Mvc" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
  Division
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

    <h2>Division</h2>

  <% using(Html.BeginForm("Division","Home")) { %>
    <%= Html.EditorFor(m=>m.Name) %>
    <h3>Boss</h3>
    <%= Html.EditorFor(m=>m.Boss) %>

    <h3>People</h3>
    <% foreach (var person in Model.People) { %>
      <%= Html.DisplayFor(m=>person) %>
    <% } %>

    <%= Html.Serialize("People",Model.People) %>
    <input type="submit" value="送信" />
  <% } %>
</asp:Content>

これを実行するとこのようにきちんと復元してくれます。

serialize1 serialize2 serialize3

@jsakamotoさん、いかがでしょうか?

2010年7月4日日曜日

Razorのポテンシャル

Introducing “Razor” – a new view engine for ASP.NET - ScottGu's Blog

↑これ読みました?

Razor View Syntax

↑これも。

これね、よくよく考えたらかなり凄いことに取り組んでるんだと思います。そもそもASP.NET MVCはASP.NETのフレームワークにのっかったものですよね。それはどういう事かというと

  • HttpApplicationのパイプラインで処理
  • HttpContextで現在のリクエストコンテキストに関する全ての情報にアクセス可能
  • System.Web.UI.PageがIHttpHandlerの実装としてPageパイプラインを処理しつつレンダリング

ですね。ASP.NET MVCのViewでは、このフレームワーク(Pageに関する部分)の使い方で変わった部分はほとんどないんですが、構造上使われなくなったものといえばコントロールツリーの構築とポストバックです。コントロールツリーに関しては「runat="server"なコントロールを使ってる場合には作られるじゃないか」と言われればそうなんですが、そこはPageクラスがそうだからで、Viewの性質として必須な機能じゃないのでWebFormとの対比という意味では使ってないと言うことにしましょう。ポストバックですが、これは特にMVC2になってから大きく変化のある部分で例えば以下の単純なViewでもIsPostBackはtrueになりません。

<%@ Page Language="C#" 
MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage" %> <script runat="server"> void Page_Load() { if(IsPostBack) { // PostBack eventはいずこ?
// ここには決して入ってこない } } </script> <asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server"> </asp:Content> <asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server"> <form runat="server"> <asp:Login ID="Login1" runat="server"> </asp:Login> </form> </asp:Content>

Viewのレンダリングの仕様が変更になってるのでWebFormViewにはイベントがイベントとして認識できない形になったから(TextWriter渡しのRender呼び出し)。ようはControllerに対するPOST/PUT/DELETE/GETのHttp MethodがViewに影響を及ぼすことを是としない、という意志の表れなんじゃないか~、なんてな。

話がずれましたがRazorはこのPageクラスに依存しないViewEngineとして造られてるので、Page Pipeline(イベント)は処理されない、コントロールツリーも構築されないという事になって、ASPX構文解析→C#生成の部分と、Razorの準備コスト(テンプレートエンジンとしてのコスト)が同程度だとしても、処理コストは低くなるのでよりスケールするフレームワークになるんじゃないかと思います。

Pageクラス(WebForms)におけるPostBackという発明はPage Controllerの素晴らしい実装だと思いますが、MVCとなればControllerは役割の違うものとして分離されてるので、PostBackは不要だし、それを実装してるPageクラスはリッチすぎるでしょう。DataSetからRepositoryへのスタイルの変化も同じような考え方からきてるんじゃないでしょうかね(メモリバウンドよりCPUバウンド的な)。Pageクラス、Page Pipelineからの脱却。凄くないですか?

と、なんの根拠もないですが、妄想したりしてます。

2010年2月28日日曜日

続Demotterについて

途中まで書いて力尽きたので、続きを。

ValuProviderFactoryについての説明まで進みましたが、そもそものIValueProviderは何なのかというところをすっ飛ばしてます。IValueProvider自体はMVC 1の頃から存在してるものです。GetValueでValueProviderResultとして値を取得するためのインターフェースです。UpdateModelなんかもIValueProviderを渡すオーバーライドがちゃんとあります。FormCollection.ToValueProvider()なんかを渡しますね。

ようは何でもいいからキーに対応する値を渡せばいいんです。基本実装のDictionaryValueProviderは値の実体そのものをキーと共に保持してるものなんですが、キーに対応する値を常に保持しておく必要はなく、GetValueのたびに取得しにいくという実装もアリです。HttpCookieValueProviderの例としてとてもいいサイトが有ります。

Dive Deep Into MVC - IValueProvider - Mehdi Golchin's blog

このサンプルコードではGetValueのたびにRequest.Cookieを参照する作りなのは、値の実体はHttpContextにそもそも保持されてるので、Dictionaryとして二重に保持する必要がないからです。ただ、これだとテストはHttpContextBaseのモック作成から必要になるんで、少し面倒ですけど。

Demotter(MvcPresetner)で作成したのは、PresentationZipValueProviderFactoryでプロジェクトルートにあるやつです。

mvcp

これまで説明したValueProviderFactoryのサンプル実装としてZipファイルをアップロードすると、サーバーサイドで解凍し、Presentationクラス(特にModelBinderの対象となるクラスを限定する縛りはないです)のインスタンスを生成するためにDefaultModelBinderから利用出来るようになっています。

なんで、ここに注目してるのかというと、SRP(Single Responsibility Principal)でテストを簡単にしたいからです。やっぱり楽して作りたいというのがあるからね。Actionのテストってモデルクラスを渡してしまえば、実行コンテキストに依存させなくてもいいじゃないです。DefaultModelBinderは標準機能だからテストなんかしなくていい。そうすると、カスタムValueProviderFactoryだけがHttpContextBaseのMockを使ったテスト対象になるわけです(ViewのテストはWebサーバーで実際に動かしてSeleniumとかでどうぞ)。素晴らしいリファクタリングだと思います。

Zipファイルを解凍するために、外部の依存アセンブリとしてDotNetZip Libraryを利用しています。ZipFileクラスのReadでZipファイルを指定し、ExtractAllで全解凍です。使ってる機能はそれだけ。

PresentationのリポジトリとしてStoragePresentationRepositoryクラスを作ってます。IPresentationRepositoryのファイルストレージ保存用の実装です。なので、ここはデータベースに保存するようなRepositoryを実装すれば、データファイルの保存場所は上位のサービス層(このサンプルではサービス層はなくControllerで直接Repositoryを使ってます)が知る必要はないような作りです。

実ファイルを”~/App_Data”に保存するようにしてるのでServer.MapPathを使う必要があり、Controller.InitializeでIPresentationRepositoryの実装クラスのインスタンスを作成してるので、LinqToSqlPresentationRepositoryを作成したとしても、単純変更はできないのが、手を抜いたところです。RepositoryのResolverというかCreatorを作っておいて、そいつに任せるようにしておく実装であれば依存性を排除できますね。

    private IPresentationRepository _repository;
    public static Func<RequestContext,IPresentationRepository> RepositoryCreator = 
      (requestContext) => new StoragePresentationRepository(
requestContext.HttpContext.Server.MapPath("~/App_Data")
); protected override void Initialize(RequestContext requestContext) { base.Initialize(requestContext); // Serverプロパティなどの参照はInitialize以降じゃないと // できないので気をつけましょう _repository = RepositoryCreator(requestContext); }

たとえば、現状のコードを↑こうしてみるとか。LinqToSqlPresentationRepositoryはRequestContextを必要としないですけど、簡単にするにはこういうのを渡すルールにしておくのもいいんじゃないですかね。Global.asaxなんかで以下のようにCreatorを変えちゃえば、うまくいくはず。

    protected void Application_Start()
    {
      AreaRegistration.RegisterAllAreas();

      RegisterRoutes(RouteTable.Routes);

      ValueProviderFactories.Factories.Add(new PresentationZipValueProviderFactory());

      HomeController.RepositoryCreator = (_) => new LinqToSqlPresentationRepository();

      // カスタムModelBinderを使うなら↓ここで登録忘れずに。
      //ModelBinders.Binders.Add(typeof(Presentation), new PresentationModelBinder());
    }

ここはMVC関係ないところ。今回のサンプルではControllerが生成されるたびに、毎回Repositoryの中でApp_Dataを見てPresentationのインスタンスを取得するので無駄が多いですが、その辺もサンプルということで勘弁してもらえると助かります。

ModelBinderは標準のDefaultModelBinderを使っていて、DataAnnotationModelValidatorがそのまま機能します。カスタムModelBinderでもDataAnnotationを機能させるなら、多分以下のような作り方になると思います。

  /// ValueProviderFactoryを定義しない従来の手法だと、ModelBinderを作成して
  /// 以下のように自分でマップしたモデルに対してValidationを実行することになります。
  public class PresentationModelBinder : DefaultModelBinder
  {
    public override object BindModel(ControllerContext controllerContext, 
ModelBindingContext bindingContext) { // ここでモデルを生成してModelMetadataに入れておくと、 // CreateModelでは生成せずに、OnModelUpdating/OnModelUpdated // を内部で呼び出してくれるようになる。 // でも、この書き方であってるのか自信無いですが...。 var valueResult = bindingContext.ValueProvider.GetValue("Name"); var model = StorageAccessor.Load(
PresentationZipValueProviderFactory.UploadTempPath,
true, valueResult.AttemptedValue); bindingContext.ModelMetadata.Model = model; return base.BindModel(controllerContext, bindingContext); } }

これがあってるのかどうかは自信がないです。BindModelの戻り値にインスタンスをそのまま返すだけではDataAnnotationが効かないので、BindingContext.ModelMetadata.Modelに対象モデルのインスタンスを入れて、後はbase.BindModelに任せてしまう実装です。いいのかな~。ちゃんと動くのは確認してます。

リポジトリから取得できたものをHTMLとして生成するために、Viewにモデルを渡し(Presentationクラスのインスタンス)、後はViewにまるなげです。

スライドとして表示したいデータをMarkdown書式で送信したものを利用するようにしてるので(Stackoverflow.comをまねっこしてみたかった)、Markdown書式からHTMLに変換する必要があります。クライアントでの変換実装としてWMDというのもありますが、今回はサーバーサイドでHTMLに変換するMarkdownSharpを利用しています。2個目の外部依存アセンブリです。Markdownで厳しいところはUL/LIの入れ子が2段までしかできないところ。できる方法があるんだろうか。当たり前ですが、利用目的がスライドじゃないのでしかたないところですね。

スライドの動き自体はカーソルの上下でフェードさせながらの切り替え、左右でアニメーション無しでの切り替えの2種類のみで、リッチなアニメーションは実装してないです。その辺はS5やS6なんかがあるので、そっちに差し替えてもらえればいいかな~、なんて。

そんなこんなで、実行すると↓こんなです。

mvcp2

後は、F11でフルスクリーン表示にしておけば、それっぽく見えます。

あとアップロードしたコンテンツの削除をHttpDelete属性を指定したActionで実装してますが、これだけだとHttpVerbs.DeleteなリクエストじゃないとActionInvokerの対象として選択されないです。一般的なブラウザではGET/POSTしか送信してくれないので困りもの。でも、MVC 2ではHttpVerbsのオーバーライドを簡単にできるように拡張メソッドも用意されてるので、HtmlHelperの拡張メソッドHttpMethodOverrideをForm内で呼び出せば、POSTでもオーバーライド(hiddenに埋め込まれる)されてうまく動くようになります。Railsなんかでも"_method"でHttpVerbsをオーバーライドできるのでそれと同じです。

Viewでは以下のように書いてます。

    <ul>
    <% foreach (var item in Model) { %>
    
    <li>
      <%= Html.RouteLink(item.Name, "Viewer", new { id = item.Name })%>
      &nbsp;-&nbsp;
      <% using (Html.BeginForm("Delete", "Home", new { id = item.Name }, 
FormMethod.Post, new { style = "display:inline;" })) { %> <%= Html.HttpMethodOverride(HttpVerbs.Delete) %> <input type="submit" value="削除" /> <% } %> </li> <% } %> </ul>

簡単ですね。

mvcp3

↑こんなボタン出てきます。なんで、わざわざHTTPメソッドでActionを選択するのかというのはRESTfulなアーキテクチャスタイルの話になるので割愛。ただ、この実装方法であれば、ブラウザ以外からDeleteやPutのリクエストと、ブラウザからの同リクエストを区別するようにActionを書かなくて済むのがいいですよね。もちろんAction名が”Remove”とか”Update”とかでPostで処理をするようにしても、結果は一緒ですけどね。

DemotterことMvcPresenterが何を実装したサンプルなのか、だいたい分かってもらえたでしょうか。これを10分で話すのはさすがに無理ですね。詰め込みすぎました。

Demotterについて

ASP.NET MVC 2になって変更された箇所はとても多いです。MVC 2での新しくなった部分を紹介するサンプルとしてMvcPresenterというのを作成することにしました。Demotterという名前はEdtterへのオマージュ(?)。

MVC 2の新機能のうちマニアにはたまらないだろうなと思って目をつけたのが各種Providerモデルへのリファクタリング部分で、MvcPresenterではそのうちIValueProviderを実装したValueProviderFactoryのカスタム化と言う部分をメインに実装しています。

いきなりそんな話をされても意味がわからないと思うので、順を追って説明していきます(ASP.NET MVCについての基本的な知識は前提です)。

そもそもMVCではポストバックがないので、TextBoxやRadioButtonなどの入力用サーバーコントロールは使用しません。HTMLとしてのinputやtextarea、selectを使用するのみです。そうすると入力値をサーバーサイドで取得するにはどうすればいいかというと以下の3通りあります。

  • Request.Formで取得
  • FormCollection型の変数をAction引数に指定する
  • ModelBinderに任せる

Request.FormとFormCollectionを使用する方法はあまりにも原始的すぎます。入力に対する検証も自分で行う必要があり、とても煩雑なコードになります。

Viewとして以下のようなものがあるとします。

  <% using (Html.BeginForm("FormPost1")) { %>
  
    <% = Html.TextBox("name") %>
    <% = Html.TextBox("age") %>
    <% = Html.CheckBox("isDeveloper") %>
    
    <input type="submit" value="do post" />
    
  <% } %>

これを受け付けるActionとしてRequest.FormやFormCollectionの場合↓こうなります。

    public ActionResult FormPost1()
    {
      var name = Request.Form["name"];
      int age;
      int.TryParse(Request.Form["age"], out age);
      bool isDeveloper;
      bool.TryParse(Request.Form["isDeveloper"], out isDeveloper);

      // 処理

      return View();
    }

    public ActionResult FormPost2(FormCollection form)
    {
      var name = form["name"];
      int age;
      int.TryParse(form["age"], out age);
      bool isDeveloper;
      bool.TryParse(form["isDeveloper"], out isDeveloper);

      // 処理

      return View();
    }

ほとんど同じなんですが、テストする際にRequestなどのコンテキストに依存させないようにするためにFormCollectionを使用するという書き方が存在します。

これに対しModelBinderを利用するスタイルの場合は以下のようになります。

    public ActionResult FormPost3(string name, int age, bool isDeveloper)
    {
      // 処理

      return View();
    }

Action引数に直接入力値が入ってきます。型変換も自動です。変換できないならエラーになるという便利なものです。でも、これだと細かく入力エラーを処理できないです。しかも値が多いとAction引数がとんでもないことになります。

なので以下のようにクラスを定義して、そのクラスのインスタンスをAction引数に取得するというスタイルがオーソドックスな手法となるはずです。

  public class Person
  {
    public string Name { get; set; }
    public int Age { get; set; }
    public bool IsDeveloper { get; set; }
  }

↑これがクラス定義で、↓これがAction。

    public ActionResult FormPost4(Person person)
    {
      // 処理

      return View();
    }

何が違うかは一目瞭然。本来personという仮引数名を使用する場合、Formのname属性にプレフィックスとして"person."とつけておくんですが、そこは自動でプロパティ名とname属性をみて一致するなら埋めてくれます。なので、あえて"person.name"や”person.age”とname属性に指定しなくてもModelBinderは賢いのでなんとかしてくれるんですね。明示的に分けたいときにname属性にプレフィックスを指定する必要があります。

クラスを指定するのも基本型を指定するのもModelBinderにしてみれば同じことです。固有のクラスを使用して、DefaultModelBinderがきちんとインスタンスを生成できないときには独自のModelBinderを作成することになると思いますが、MVC 2ではそういう手法はあまりとらないんじゃないかと思ってます。理由はValueProviderFactoryが指定できるようになったからです。

不思議に思わないですか?Routeに指定した場合でもAction引数に割り当てられるし、FormからPostしても割り当てられる。もちろんQueryStringの場合でも自動でAction引数に値がわたってくるんですよ?データの出所がそれぞれ違うじゃないですか。RouteとQueryStringはURLだから同じだと見ることもできるんですけど。

ここで、もうひとつ忘れてはいけないのがUpdateModelとTryUpdateModelです。これはIValueProviderを指定するか、Formの値を利用するかのどちらかでクラスのインスタンスを生成してくれるんですが、それもValueProviderFactoryを利用することでデータの出所を意識しなくても良くなります。

さっきから"データの出所(でどころ)"という言葉を使ってますが、それってどういう意味かというと、ModelBinderが値を復元する際にどこから値を持ってくるのか?ということです。Request.FormなのかRequest.QueryStringなのか、RouteData.Valueなのか、ですね。じゃーRequest.Cookieから復元させたいときはどうすればいいと思いますか?MVC 1の時はAction内でRequest.Cookieを直接みて自分で変数に割り当てるか、カスタムModelBinderを作成し、そこでRequest.Cookieを参照してモデルに復元させる必要がありました。MVC 2になるとデータの出所をValueProviderFactoryから取得するという仕様になっているので、カスタムなValueProviderFactoryを作成し、Global.asaxでValueProviderFactoriesに追加しておけば、標準のValueProviderFactoryで見つからなかった場合、カスタムValueProviderFactoryから値を取得して、ModelBinderが値(クラスのインスタンスか基本型)を復元してくれます。Cookieから値を取得して復元させたければ、ModelBinderを作成するのではなく、そこはDefaultModelBinderに任せたまま、CookieValueProviderFactoryを作成するとなるでしょう。そうすることでDataAnnotationも有効な状態で値を取得できます(カスタムModelBinderでもできますがそれはまた別の時に)。

ModelBinderのデータの出所(データ取得元)を自分で好きなように指定できるということです。すごいことですよね。ちなみにValueProviderFactoryとして実装しなければいけない唯一のメソッドは

public override IValueProvider GetValueProvider(ControllerContext controllerContext)

です。IValueProviderの基本実装はDictionaryValueProvider<object>で、KeyValueなディクショナリです。ModelBinderの仕組みそのものはMVC 1の時から変わってないので、詳細ははしょりますが(書いたほうがいいですか?)、キーとしてForm要素のname属性やQueryStringのKeyを指定するのを想定して値を取得します。

なのでDictionaryとしてCookieから取得した値を返そうが、JSONをデシリアライズしてキー指定で取得できるようにしたものを返そうがXMLをキー指定で取得できるようにしたとしても、Dictionaryとして取得できるならなんでもいいんです。データの出所だけではなくデータのフォーマットにも依存させなくて済むということです。

JSONとして以下のようなデータがあったとしましょう。

{
  name:'たけはら',
  age:15,
  isDevelopper:true
}

ここから以下のように値が取得できるDictionaryを返すことができれば、ModelBinderは値を復元できるということです。

dict["name"] = "たけはら";
dict["age"] = 15;
dict["isDeveloper"] = true;

おなじ理屈でXMLでもいいですよね。自分で取りやすいスキーマさえ定義しておけばいいので。つまり、ファイルシステムにKeyValueでアクセスできるValueProviderFactoryを作成するなら、Zipでアップロードしたファイルを解凍し、フォルダ構造とファイル名がキーになっていてファイルの実体が取得できるようなものも作成できるわけです。実際にファイルの実体をbyte[]なんかで復元するのはリソースの無駄遣いになるので、ModelBinderが復元するのはファイルのパスにしておくというのが現実的でしょう。MvcPresenterがまさにそのように処理をしています。

ちょっと長くて疲れてきたので、続きは今度にしてもいいですかね。いいですよね。中途半端でさーせん。眠いっす。

2010年2月24日水曜日

ダイヤモンドは砕けない

ゆりかもめに初めて乗りました。

techdays2010 

わーい、自由の女神だー。あははー。あはははー。はぁ...。

台場でTechDays2010のBoFに出てきたんです。

4 の時代の Web アプリケーションを語ってみよう

小野さんとナオキさんと三人でのおしゃべりはTechEd 2009の時とあわせて2度目です。相変わらず打ち合わせとかしないのにはヒヤヒヤです。

ASP.NET 4になっていろいろすごいじゃないですか。その辺の話をしましょうよ、ということだったので、たけはら担当はもちろんASP.NET MVC 2。一応事前に書いておいたメモをブログにも載せておきます。

メジャーな部分

  • データ検証の方法がDataAnnotationsを基本にしたものになりました。

これまで通りIDataErrorInfoを実装したものも有効ですが、ValidationAttributeをモデルまたはモデルプロパティに指定(ModelMetadataで外部に定義したものでも可能)して、DataAnnotationsModelValidatorを使用するようDefaultModelBinderが変更になっています。
LinqBinaryModelBinderも標準実装に組み込まれたので、System.Data.Linq.Binary(SqlDbType.Timestampなど)をbase64でhiddenからポストしたときも、自動で復元されます!
またLinqBinaryModelBinder、基底クラスのByteArrayModelBinder(byte[]を復元)もFuturesから昇格です。

  • ASP.NET 4で組み込まれるSystem.Web.IHtmlStringを使えるようにMvcHtmlStringクラスが導入されました。

MvcHtmlStringのソースファイルを確認するととても勉強になります。まさに黒魔術。
すべてのヘルパーはstringではなく、このMvcHtmlStringを返すよう変更されています。
<%: expression %>としている場合、自動的にHtmlEncodeした結果がレンダリングされるので、今後はこれが主流になります(きっと)。
MVC2の実装でもそうですが、2.0ベースのSystem.Webにはそんなものないので、なので、ASP.NET 4じゃない場合はこれまで通り、Html.Encode(string)を使いましょう。
IHtmlStringの場合、<%: ihtmlstring %>となっていても、HtmlEncodeをかけずに出力するので、Partial HTMLをレンダリングする場合(ヘルパーのレンダリングとかも)は、IHtmlStringとして渡しておきましょう。

  • AcceptVerbsAttributeがHttpVerbs.Get/Post以外に、Put/Delete/Headにも対応するようになっています。

Get/Post以外は通常、ブラウザからは送信されないですが、HtmlHelper.HttpMethodOverride()をformタグ内で呼んでおくことで、hiddenにX-HTTP-Method-Overrideという名前で、メソッドオーバーライドを保持するようになり、POSTを使ったHttpVerbsの上書きができるようになります。
この辺の実装はHttpRequestExtensionsに用意されてるHttpRequestBaseに拡張メソッドとして実装しているGetHttpMethodOverride()がまるっと処理してくれるようになっています。
もちろんここも、AcceptVerbsAttributeの判定メソッドがoverride可能になっているので、独自のAcceptVerbsAttributeを実装することで、Railsライクに"_method"というオーバーライドを使うように変更することも可能です!
これは今までのバージョンではとても面倒な実装 にしないとできない部分でした。
ちなみに、RESTfulなController実装をするときに、これができないと、ブラウザからのリクエストと、その他のクライアントからのリクエストの処理を簡単に切り分けできなくてとても不便です。

  • JsonResultを返すActionの場合、HttpVerbsがPOSTであることが基本条件になりました。

セキュリティ的にゴニョゴニョらしいです。

  public ActionResult Json()
  {
    //var json = Json(new {result = "json!"});
    //json.JsonRequestBehavior = JsonRequestBehavior.AllowGet;
    //return json;
return Json(new {result = "json!"},JsonRequestBehavior.AllowGet); }

Getなら↑これで大丈夫。

修正:2010年3月9日

  • DefaultControllerFactoryからRequestContextプロパティが無くなりました。

依存性をなくすのはいいことです。その代わり、Controllerのインスタンスを生成するためのCreateControllerにRequestContextをパラメータとして渡すようになってます。
Mockを作る時が楽ちんです。

  • AreaをサポートするためにRouteData.Valuesで"area"が予約されるようになりました。

自分仕様でこの名前の値を使ってる場合は変更しておきましょう。

  • Html.Substituteは残念ながら使えなくなりました。
  • クライアントサイド検証が標準で組み込まれてます。

このクライアントサイドコードを生成するために、C#からJavaScriptを吐き出す
ScriptSharpが使われています。
コード生成に興味がある方は、参照してみるといいんじゃないかと思います。

Script#
http://projects.nikhilk.net/ScriptSharp

ボスが最近似たようなのを見つけてはしゃいでました。

SharpKit - Write C# instead of JavaScript
http://sharpkit.net/

  • Templateベース

DynamicDataと同じようにTemplateベースのモデルレンダリングを実装したHtml.EditorForやDisplayFor、プロパティベースのレンダリングを行うTextBoxForやLabelForなんかも目が離せない便利機能です。
System.ComponentModel.DisplayNameAttributeやUIHintAttributeを使ってカスタマイズもしやすくていいですね。

注目機能

  • ChildActionOnly属性

HtmlHelperのRenderAction/Actionからの要求しか受け付けないようにするActionFilter。

  • UrlParameter.Optional

Route登録時にRouteData.Valuesにキーすら含ませないようにするオプション。

Deep Dive!

一番注目したいのはASP.NETらしさをしっかり継承したProviderモデルへのリファクタリングです。マニアックな部分ですが、拡張性を考慮して、より自由どの高い開発を行えるよう沢山のフックポイントを提供するために実装されています。処理の流として入力→検証(Model)→処理(Controller & Model)→出力(View)
というフローになるそれぞれのつなぎ部分で拡張できる感じです。

MVCソースから"Provider"と付いているクラスを検索!

  • ModelMetadataProviders
    • ModelMetadataProvider
      • AssociatedMetadataProvider
        • EmptryModelValidatorProvider
        • DataAnnotationsModelValidatorProvider

ModelMetadataを取得するためのプロバイダ。
モデルやモデルプロパティに関するすべてのメタ情報。
ValidationAttributeの定義や、型情報、出力方法など。

  • ModelValidatorProviders
    • ModelValidatornProvider
      • AssociatedValidatorProvider
        標準のValidationAttribute用のAttributeAdopterクラスとDataAnnotationsModelValidatorを管理。
        • EmptryModelValidatorProvider
        • DataAnnotationsModelValidatorProvider
      • DataErrorInfoModelValidatorProvider
        IDataErrorInfoの実装に対するDataErrorInfoPropertyModelValidatorとDataErrorInfoClassModelValidatorを使って、検証の結果を取得する。
      • ClientDataTypeModelValidatorProvider
        数値型に関するNumericModelValidator。
    • DataAnnotationsModelValidatorProvider
    • DataErrorInfoModelValidatorProvider
    • ClientDataTypeModelValidatorProvider
  • IValueProvider
    • NameValueCollectionValueProvider
      • FormValueProvider
      • RouteDataValueProvider
      • QueryStringValueProvider
    • HttpFileCollectionValueProvider

ModelBinderがモデルにデータをバインドするさいに、値を取得する際に利用する。データの出所がどこなのかをModelBinderは意識しなくてもいいんです。

次に"Factory"とついたクラスを検索!

  • DefaultControllerFactory
  • ValueProviderFactories
    • ValueProviderFactory
      • FormValueProviderFactory
      • RouteDataValueProviderFactory
      • QueryStringValueProviderFactory
      • HttpFileCollectionValueProviderFactory

コントローラの生成用のControllerFactoryと、IValueProviderを実装したValueProviderFactoryたちの2種類です。これがリファクタリングした超重要な部分になります。

で、後は、これらを利用したサンプルの紹介という流れです。

MVC Presenter

↑これね。このサンプルそのものがWebアプリケーションになっていて、サンプルの実行そのものがプレゼンスライドの表示になるという仕掛けだったんですけど...。

プロバイダモデルがうんぬんくらいからちょっとツマラナイ話になってしまいましたね。今回はコードに関する説明がごっそりできてないので、MVC2の良くなった部分がサンプルのどこにどう使われているのか、全然伝えられませんでした。反省してます。Zipで圧縮したのをアップロードしてどうのこうのとか、実はパワポじゃないんだよとか、それ以前に何を伝えようとしてるのかが、伝えられてなかったです。ドン引きってこんな時に使うのかな。

心が折れて、帰りのゆりかもめでは夕日が目に染みた。泣いてなんかないやい。

JOJO'S BIZARRE ADVENTURE Part4 Diamond is not Crash

けど、魂を砕くことはできないぜ!また機会があったら、今回の教訓を生かし、もっと参加者に楽しんでもらえるよう的を絞ったプレゼン+コードにしようと思います。

サンプルの説明を近いうちここにエントリしようと思います(ここ知らない参加者の方には申し訳ないですが)。

2010年2月15日月曜日

Sauce IDE+RCはFirefox+Firebugでの使い勝手がとてもいい

Webアプリのテストの定番といえば、SeleniumかWatiNなのかな、というレベルのWebアプリテスト初心者ですが、Seleniumの後継にあたる(この辺あいまい)Sauceっていうのを試してみたよ!

Products - Sauce Labs

まだないけどいつかDimeCastsでビデオが公開されるに違いない。

試すにあたり、何かしらプログラムが必要だろうと、昨日ハンサムスーツを見ながらシンプルブログ(全然ブログじゃないというのは本題じゃないYO!)を作ってみた。

タイトルいれて本文入れるだけね。せっかくだからASP.NET MVC RC2で。話はそれるんだけど、RC2のItem Templateはイマイチかも。TextBoxForなんかは新しいTemplateベースのDisplayForやEditorForに揃えてくれるともうちょっと素敵さが増すんじゃないかな~。せっかくDataAnnotationsでDisplayName属性を指定してもLabelForで展開しないとそこから表示名を取得してくれないじゃないっすか。Listテンプレートは面倒かもしれないけど、そうじゃないところはDataAnnotationsの属性を生かせるヘルパーを使った物に統一してもらいたいデス。せっかくUIHintでカスタムEditorTemplatesを指定しても効いてくれなくてちょっと切なかった。

sauce1

↑一覧ページ。殺風景ですいません。

sauce2 sauce2_2

↑新規ページ。同じフォーマットで編集ページもあるよ。ここで入力エラーがあると、DataAnnotationsがバシっと効いてくれるのがV2の素敵なところ。

sauce3

↑新規登録すると一覧に表示されるよ。殺風景ですいません。

sauce4

↑詳細ページ。コレといって何も無いですね。あ、本文にはHTMLが入るイメージなのでHTMLエディターをEditorTemplatesで作ってもいいね。今ならMarkdownのほうがオシャレかの~。

sauce5

↑削除ページ。削除すると、一覧ページに戻るだけ。

とりあえずこんなのを作って、これに対してテストを実施させてみようじゃないですか。

実行したいテストは以下の通り。

  1. 1件も登録されてない状態で新規登録
  2. 1件以上登録されてる状態で新規登録
  3. 未入力状態でCreateを押してモデル検証をエラーにする
  4. 登録されているすべてのエントリを削除する

今回認証は無しで。

そもそもSeleniumすら使った事ないけど、まずはSauce LabsのProductsトップにあるビデオを確認。ふ~ん、ってなもんです。とにかく、Sauce IDEをFirefoxにインストールして、Sauce RCをローカルPCにインストール。まずはこれでいいっぽい?う~ん残念。Selenium RCをダウンロードしておかないとUnit TestをC#で実行できないみたいです。

Sauce IDEがテストレコーダーで、Sauce RCがテスト実行サーバー、Selenium RCがテストを実行させるのに必要なアセンブリ(Sauce RCサーバーとの通信を行う)を提供、って具合の理解でよろしかろうか。Sauce RCはJavaアプリで、Webベースの管理インターフェースもありそこでテスト実行ブラウザやその他設定の変更ができると。

sauce6

テスト実行する場合、ブラウザを起動してそのブラウザをコントロールすることでテスト実行と結果取得する仕組み?Sauce IDEが表示してくれる、C#のコードはNUnitを基本になってて、そこはMSTestでよしなに動くようにチョチョッと変更。大枠はTestInitializeでDefaultSeleniumを初期化するようにするのと、TestCleanupでDefaultSeleniumの停止処理、あとはひたすらテスト書く。

    private ISelenium selenium;
    private StringBuilder verificationErrors;

    [TestInitialize]
    public void Setup()
    {
      selenium = new DefaultSelenium(
"localhost",
4444,
"*firefox",
"http://localhost:20337/"); selenium.Start(); verificationErrors = new StringBuilder(); } [TestCleanup] public void TeardownTest() { try { selenium.Stop(); } catch (Exception) { // Ignore errors if unable to close the browser } Assert.AreEqual("", verificationErrors.ToString()); }

あと、ちゃんとSelenium RCのダウンロードしたアセンブリをテストプロジェクトでは参照設定しとこうね。

DefaultSeleniumの1個目と2個目のパラメータはなんじゃらホイ。3個目はブラウザっぽくて4個目がテスト対象アプリのアドレス。どうもこの1個目と2個目がSauce RCのサーバーらしい。RCの制御用Webインターフェースはhttp://localhost:8421/ でポートが8421。実際のアプリはポートが20337と、いろいろ仕組みを理解しておかないと~。Sauce OnDemandっていうクラウドサービスもあるからね~。

上記初期コードを書いておけば、あとはIDEの出してくれるC#コードをコピペっちょ!なんだけど、それだと思ったようなエレメントを指してくれない。実行結果のHTML全体に文字列が含まれてるかをチェックするIsTextPresentなんかを使うのはテストとして成立しないっすよね。

なので、エレメントの参照はCSS SelectorかID指定かXPath指定がオーソドックスな指定の仕方になるかと思うわけです。でね、Firebugってさ、前バージョンまでは別途Plug inを入れないとXPathの取得ってできなかったけど新しいバージョンになって”XPathをコピー”っていう機能が標準で実装されてるじゃないですか。

sauce7

↑エレメントのXPathが表示されてるから↓右クリックでコピーだ!

 sauce8

で、対象となるエレメントを特定するためのXPathは何の苦労もなく取得できちゃうので、テストコードのアサーション部分やClick対象のエレメントなんかもこれを使って一意に特定だぜ!

    [TestMethod]
    public void A_First_Entry()
    {
      selenium.Open("/");

      selenium.Click("link=Create New");
      selenium.WaitForPageToLoad("30000");
      selenium.Type("Title", "first");
      selenium.Type("Body", "最初のエントリ");
      selenium.Click("//input[@value='Create']");
      selenium.WaitForPageToLoad("30000");

      Assert.IsTrue(
        selenium.GetText("xpath=/html/body/div/div[2]/table/tbody/tr[2]/td[2]") 
        == 
        "first");

      // 最初のDetailsをクリック
      selenium.Click("xpath=/html/body/div/div[2]/table/tbody/tr[2]/td/a[2]");
      selenium.WaitForPageToLoad("30000");

      Assert.IsTrue(
        selenium.GetText("xpath=/html/body/div/div[2]/fieldset/div[4]")
        ==
        "最初のエントリ");
    }

↑こんな感じで入力値と入力結果を比較してちゃんとHTML的に想定通りの結果が生成されてることをテストコードに書けちゃうのが素晴らしい。無知って怖い。これまで自分は一体なにをしてたんだと言いたい。

これらテストを実行する時に、MSTest(かReSharperのテストのどっちがそういう仕様なのかは知らないけど)だとテストメソッド名順に実行されるので、テスト内容が直前の実行結果に依存するような場合は、プレフィックスを決めておく必要があったりしそう。テストクラスそのものを分けてしまうのもありだけどね。

実行すると、ブラウザが起動してあとは勝手に処理してくれるっす。

sauce9  sauce10

↑これがFirefoxで実行してるところ。

sauce11

↑こっちがIEで実行してるところ。

ブラウザの切り替えはTestInitializeの設定じゃなくて、Sauce RCの設定画面が優先、っぽい。何にせよ、初めてのWebアプリのユニットテストとしては好感触。今後も精進していきます。

今回のサンプルアプリとテストコードは↓こちらからどうぞ。

※ちなみにサンプルアプリ自体のテストコードはないのであしからず。

dotnetConf2015 Japan

https://github.com/takepara/MvcVpl ↑こちらにいろいろ置いときました。 参加してくださった方々の温かい対応に感謝感謝です。