Bloggerをいじる

とりあえずは、コードをエントリーに書くことが多くなるとは思うので、綺麗に見せるためにGoogle Code Prettifyを導入してみる。

google-code-prettify - Google Code

ここからコードをダウンロードできるんだけど、はて、このJSファイルとCSSファイルはどこにアップロードするんでしょうね。困りますね。面倒なのでずるいとは思いつつ、SVN-Tranc(google-code-prettify - Revision 64: /trunk/src)から直接貼り付けちゃった。てへ。

テンプレートを編集する画面でheadタグ内の<title>の下にダイレクト挿入！

<script src='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.js'
       type='text/javascript'/>
<link href='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.css'
     rel='stylesheet' type='text/css'/>

後は、コードを載せたい箇所を<pre class=”prettyprint”></pre>で囲むだけ！ とは言ってもですね、毎回ソースを開いてそんなことやってられないじゃないか！ 便利な物はないかな～、と思って行き着いたのが「Windows Live Writer用のプラグインを開発する：CodeZine」。

おっと、いきなりプラグイン開発ですか？そうですか。それもやむなしですね。どれどれ、記事を読んでみると大して難しいことしなくてもこの程度のことならサクッと作れそう。だってpreで囲むだけだし。SmartContentSourceじゃなくてContentSourceで作れるじゃんね。んで、作ったDLLをPluginフォルダに入れとけばイイみたいだし。良し作るか。と、思ってちなみに同じ事考えてる人いるんじゃないかと思って、改めて検索し直してみたら板いた。Vistaのサイドバーガジェットの時の無駄作業を思い出して良かった。あのときも同じようなの作ってる人いたもんね。ちゃんと調べないで作っちゃって損した気分になったし。

Code Prettify for Windows Live Writer – Home

コード見たらビックリだね。こんなに潔いプラグインも珍しい。いや、だって、自分でもきっとこう書く。

次にデフォルトのコメントシステムはいきなりスパムが来たりするくらいなので、速攻で消してとりあえずFriendConnectにしてみたんだけど、TumblrでTypePad Connectを使ってるの思い出した。

Bloggerもサポートしてるよ！と豪語してるだけあって、設置方法もスクリーンショットでテンプレート編集箇所を書いてあったりして、親切だ。

でも、動かなかった。 だいたい、書いてあるとおりにやってみたけどダメだった。Bloggerのテンプレートがどうなってる(構造が)のか調べるのも面倒だしな～。このブログに適用してるブログにはそもそもインストール手順に書いてるような項目もないし。インストール手順がデフォルトテンプレートを基準にするのは、そりゃあたりまえだしね。違うデザインのテンプレートを使ってるんだから致し方なし。

かといって、諦めるのはダンディじゃない。 無理矢理にでも動かしてやる。大まかな手順は３つ。

１．コメントフォームとコメント一覧を表示する部分のコードを貼り付け。 ２．コメント件数を表示するアンカーを貼り付け。 ３．コメント件数を表示するスクリプトを貼り付け。

１と３の作業は手順書通りに出来そう。ちゃんと該当箇所も見つかるし。 ２の作業は．．．。今度は手順書の場所が見あたらない。なんか、ちょっとテンプレートが違う。

でも、まぁ、同じようなモンだろう、ってことで、↓こんな感じで貼り付けてみた。

    <b:if cond='data:post.allowComments'>
     <h4>
       <b:if cond='data:post.numComments == 1'>
         1 <data:commentLabel/>:
       <b:else/>
         <data:post.numComments/> <data:commentLabelPlural/>:
       </b:if>
     </h4>
    <b:else/>
     <a expr:href='data:post.url + "#comments"'>Comments</a>

で、動かしてもこれがちゃんと表示してくれないんだよね～。 上のコードのリンクは表示されてるんだけど、入力フォームが出てこない。こりゃどうしたものか。 出てこないってことは、貼り付ける場所を間違えてるんだろう、と。 絶対出てくるところに貼り付ければいいじゃん。 ってことで、上記Commentsリンクの直下に貼り付けてみた。

    <b:if cond='data:post.allowComments'>
     <h4>
       <b:if cond='data:post.numComments == 1'>
         1 <data:commentLabel/>:
       <b:else/>
         <data:post.numComments/> <data:commentLabelPlural/>:
       </b:if>
     </h4>
   <b:else/>
     <a expr:href='data:post.url + "#comments"'>Comments</a>
<!-- START TypePad Connect -->
<b:else/>
<div class="comments-content">
～ここに手順書のコード～
</div>
<!-- END TypePad Connect -->

これで、どうかな～。うぬ。ちゃんと出るね。

ということで、Friend Connectは削除して、コメントシステムはTypePad Connectで一本化です！ スッキリした。

LINQで今日以降今年いっぱいの日曜の日付を表示

LINQ練習 #1 「LINQ to Object 基本」 - 悠希 - builder by ZDNet Japan

ここで書かれてるコードが↓これ。

List<DateTime> list;
list = new List<DateTime>();
for(int i=0;i<=365;i++) list.Add(DateTime.Today.AddDays(i));

int nowYear;
nowYear = DateTime.Today.Year;
var sunday = from M in list
            where M.DayOfWeek == DayOfWeek.Sunday &&
                  M.Year = nowYear select M;

foreach (var row in sunday) {
   Console.WriteLine(row.ToShortDateString());
}

※今年かどうか判定する条件の部分が代入になってるよ～。

せっかくLINQを使うっていうお題なんだから日付の生成部分もList<DateTime>に生成して入れておく、なんてことをしないで、そこもLINQに含めちゃった方がオシャレ感でると思うよ～。そう、例えば↓こんな感じでね。

var today = DateTime.Today;
var sunday = from date in
             from day in Enumerable.Range(0, 365)
             select today.AddDays(day)
            where date.DayOfWeek == DayOfWeek.Sunday &&
                  date.Year == today.Year
            select date; 

心機一転

ブログをBloggerに移行します。 FeedBurner経由でFeedを購読してる場合は、そのままのでOKです。 特に、現在がんばってるASP.NET MVCに関するエントリーは移行しました。 が、その他のエントリーは、移行せずそのままにしておきます。 今後、こちらのブログでの更新がメインになります。 あと、Tumblrはそのまま継続使用デス。

BloggerのRate Limit

まさか、自分がこの制限に引っかかるとは．．．。 調子に乗って、前ブログからエントリーを移行させるという行為が仇になった。 24時間で解除されるみたいだけど、それまでWindows Live Writer経由でのエントリーが出来ませぬ。 Windows Live Writerで書き込もうとすると．．．。

400 Bad Request Blog has exceeded rate limit or otherwise requires word verification for new posts

と、悲しいメッセージが出てくる。 50件あたりで出てきた気がする．．．。切ないね～。 ブラウザ経由でも、API経由でも出るみたいだから、一気にやるならImport機能のフォーマット似合わせたXMLファイルを作成して、それを取り込むのがいいんだろうね。 面倒くさいな～。特に、画像をPicasaに入れてimgタグのsrc書き換えとかゲンナリするし。 まぁ、ASP.NET MVC関係のエントリだけを移行させようと思ってるから手作業でやるさ。

ASP.NET MVCとGearsの連携

Maarten Balliauw {blog} - Creating an ASP.NET MVC application with Google Gears

面白いエントリー発見。 Gearsは最初のリリースの時に少し触ってみた程度で、名前からGoogleが消えたあたりから全く状況を追いかけてないんだけど、このサンプルがかなり面白い。

エントリーには２つソリューションがあって、１つはMVCオンリーでもう一つがGears対応版。両方見比べると分かりやすいんだけど、なにせDBファイル込みになってるから少しサイズが大きいのが難点。今時気にしないか。

どっちにも共通して存在してる(デフォルトで作成されるファイルを除く)のが、NoteControllerとそのView達(List/Detail/Edit/Create)。

で、Gears対応版では、Routeにmanifest.jsonへのリクエストに応えるためのルート登録をして(GearsController)、関連jsファイルが含まれててそれをインクルードするためにSite.Masterが少し違うだけ。

MVC部に注目してみると、GearsControllerのIndexアクションが~/Contentと~/Scriptsフォルダの全ファイルのURL、それとMVCがViewを返すURL(/Homeや/NoteList)、データ詳細のURLをJsonで返すだけに見える。

一体全体どこでデータとViewのHTMLとを分離するコードがあるんだろう。テンプレート的な物が定義されてるんだとばかり思ってたけど、そんなコードが見あたらない。

demo_offline.jsはGearsを有効にしたり、無効にしたときのローカルストアの操作と、完全オフラインになったときに編集用リンクを無効にしたり、オフラインかどうかを監視するコードだけっぽい。 gears_init.jsはいじらないコードだよね。

formやinputのname属性とかを見て自動で判断してくれてるのかな。それともシンプルに各URLに対するアクションをすべて記録してて、オンラインになったときに再生？ ちゃんとGearsの仕様を確認すれば分かることなんだろうけど、まぁ、ねぇ。今はそんなに興味ないって言うか。

それにしても、Gearsはずいぶんスゴイ事になってる気がするし、MVCとの連携がこれほどシンプルに出来るのもViewStateとPostBackがないおかげだよね。

DataAnnotationsだけでの入力検証の盲点

以前の投稿(ASP.NET MVC RCの入力検証)で、如何にASP.NET MVCのDefaultModelBinder(IModelBinder)が汎用的になったかを取り上げましたね。

で、以前の投稿で見事に見逃してたのが「必須入力ではないけど、入力形式の不正メッセージを表示したいな」というところ。分かりにくいですね。例えば日付フィールドがあってモデルのプロパティはDateTimeなら当然日付形式の文字列じゃないとキャスト出来ないから、入力エラー。数値型ならintで当然アルファベットとか勘弁してくれよ、と。

必須フィールドならRequire属性でいいですよね。キャストに失敗した場合、何もセットされず型初期値(default(T))が入ったままだから、エラーメッセージに「ちゃんと入力してね(ハート)」って表示すれば。それでも、初期値が数値で0だと困る！って時にはNullable<Int32>とかでnullにしとけば、初期値のまま処理が進んじゃうって事も防げますから。

だけど、必須じゃない場合に「キャスト出来ませんでした」なんていうシステム固定のメッセージを出すのは、どうなのよ、なんて時があるもん。社内システムとかならそういうモンだから、で済むかもしれないけど、ネットに公開するならそういうメッセージはダサイ。いや、社内システムでもダサイけど、対象ユーザー層を考えれば、それでもまぁいいじゃん、っていうかね。

ちなみに、DataAnnotationsを使って、入力検証を実装した以前の実装だと、キャストエラー表示してくれないもんね。ModelStateDictionaryには(モデルを復元したタイミングで)ちゃんとエラーとして入ってるんだけど、ModelErrorクラスのErrorMessageにはメッセージが入って無くて、Exceptionプロパティに例外情報として入ってるから展開されないんです。

以前のテストプロジェクトにここで登場してもらいましょう。で、1箇所変更点として、PersonViewModelクラスのAgeプロパティについてるRequire属性を削除して、Range属性だけにしてみます。クラス定義は以下の通り。

public class PersonViewModel : BaseViewModel
{
 public int Id { get; set; }

 [Required(ErrorMessage="名前は？")]
 public string FirstName { get; set; }

 [Required(ErrorMessage="名字は？")]
 public string LastName { get; set; }

    [Range(0,150,ErrorMessage="0歳から150歳で")]
    public int? Age { get; set; }

 public List Weapons { get; set; }

 public PersonViewModel()
 {
   Weapons = new List();
 }

 public override string Error
 {
   get
   {
     if (Weapons == null || Weapons.Count == 0)
       return "武器、っていうか必殺技は？";

     return null;
   }
 }
}

太字のところですね。 これで、入力値に整数以外を入れて、ポストしたときのスクリーンショットが↓これです。

ViewがRenderされるときに、ModelStateDictionaryがどうなってるかをブレークポイントをセットして確認してみましょう。

クリックすると大きく見れます。 Render時には、ModelState内のModelErrorは存在してるけど、ErrorMessageは""空文字で、ExceptionにInvalidOperationExceptionが入ってるのが分かります。

で、このExceptionをエラーメッセージとして表示するなら、そのまま取り出して、ErrorMessageに入れてしまうようなコードを書いてしまえばいいですね。ただ、エラーメッセージが今回の場合だと「17a は Int32 の有効な値ではありません。」と、出ちゃうんですよね。Int32って．．．。そんなこと表示されても普通の人は理解できないし。そもそもどのタイミングでメッセージの取り出し処理をすればいいでしょうね、って展開になります。

そこで、登場するのがIModelBinderのオーバーライド出来るメソッド群。これまたオレルールの方のエントリーの一番最後に書いてるIModelBinderのイベント発生順がキーになります。

結論から言うと、OnModelUpdatedのタイミング(モデルの復元完了時)に、ModelStateDictionary内のModelErrorに上記例外が含まれてるかチェックしてしまえばいい、という事になります。 ドンドン意味の分かりにくいエントリーになってきてますね～。

で、コードとしてはシンプルに↓こんな感じで動きます。LINQ部がかなり適当．．．。

public class ValidateModelBinder : DefaultModelBinder
{
 protected override void OnModelUpdated(ControllerContext controllerContext, ModelBindingContext bindingContext)
 {
   base.OnModelUpdated(controllerContext, bindingContext);

   var modelStates = bindingContext.ModelState;


   // ここでModelStateDirctionaryにInvalidCastExceptionを含んだエラーが
   // ないかチェックして、あれば入力エラーメッセージをここでいれる。
   // ※表示するときに空メッセージ(InvalidCastException)は除外するから、
   //   コレクションには入れたままにしておく。
   // ModelErrorを消さずにそのまま残しておくことで、ViewPageでCSSクラス名
   // が追加されてどのフォームエレメントがエラーなのかは視覚的に
   // 判断できる。
   var key = "__InvalidOperationException__";
   if (!modelStates.Keys.Contains(key))
   {
     var isInvalidCast = (
                           from ms in modelStates
                           from err in ms.Value.Errors
                           where err.Exception is InvalidOperationException
                           select err
                         ).Count() > 0;
     if (isInvalidCast)
       modelStates.AddModelError(key, "入力形式の間違った項目があります。");
   }
 }
} 

こんな感じで、DefaultModelBinderを派生させたクラスを作成し、このModelBinderをDefaultBinderにしちゃいます。もう、これだけでいいっす。 なので、Global.asaxのApprication_Startの所に以下のコードを追加。

protected void Application_Start()
{
 RegisterRoutes(RouteTable.Routes);
  ModelBinders.Binders.DefaultBinder = new ValidateModelBinder();
} 

特定のViewModelでしか使わないよ！っていうならViewModelクラスの宣言時に

[ModelBinder(typeof(ValidateModelBinder))] public class モデルクラス {…}

って、書きましょう。

この状態で、もう一度動かしてみます。

今度はちゃんと、ValidationSummary()で表示されるようになりました。 今回のコードは無理矢理エラー項目のキーに"__InvalidOperationException__"と入れて、複数のエラーメッセージが出ないようにしてますが、もちろん項目毎に表示してもいいですよね。

若干気になるのは、なんでInvalidOperationExceptionを発生させるようにしてるのかな～、というところ。なんとなくだけど、InvalidCastExceptionのほうがシックリ来ないですかね～。そういうもんなんですか？ ちなみにどこでInvalidOperationExceptionを発生させてるかというと、ASP.NET MVCに含まれるValueProviderResultクラスのConvertSimpleTypeメソッド。この中でTypeDescriptor.GetConverter()で取得したコンバーターのConvertToを呼び出すところらへん。

ココまで書いて思ったんだけど、ASP.NET MVCに関するエントリーだけでも全部こっちに持ってくればいいのかな。今はそれ以外の事を書く事もほとんどないし。そうしちゃおっかな。

ASP.NET MVCのエントリは全部移行しました。手作業で．．．。

なにを～！タイムリー過ぎるぜ！

You Still Can’t Create a jQuery Plugin? – NETTUTS

まだ、作ったことないっていうかjQuery自体まだ使ったことないってばよ。fnに入れればいいんでしょ？

そのくらいしか、知識がないので、ビデオでお勉強。
シンプルなプラグインだけど、まずはシンプルな物を理解しないとね！

(function($){
…
})(jQuery);

っていうのは基本みたい。jQuery本体を引数に渡して$でショートカット。

ちょっと、不思議に思ったのがthisの扱い。
Enumerable(っていうのかな)なリストに対して、プラグインを実行すると、プラグイン内でのthisがこのリストを指す。プラグイン内でそのリストをeachで回したときのthisはDOMエレメント(だよね？)。だからeach内では$(this)でjQueryでかぶせて色々便利になるようにしないといけない。

hoverに渡すfunctionがmouseenterとmouseoutの両方なのが素敵な感じがする。
ビデオ中ではmouseoutの時に$(‘tooltip’).hide()って書いてるけど、これじゃ、無限に同じIDのtooltipが出来ちゃうからダメじゃん！と思ってたけど、デモで使ってるコード(ブログエントリの最後のコードも)ではちゃんとremove()になってる。前もそうだったけど、ここで取り上げるビデオな何かしら引っかけがあるよね。

最後に、チェインするためにreturn thisでエレメントのリストをそのまま返すあたりも、jQuery流なのかな。これしないと、"."で区切って続けていろいろ出来ないもんね。

この例だと、fnに単一のfunction(内部では無名関数使ってるけど)を入れてるだけの、シンプルな物だけどもっと大きなプラグインを作る時にはどうするか気になる。けど、そこはすでに公開されてる他のプラグインをいくらでも参照すればいいから、さぁ、作ってみよう！って言うときにはそれほど問題にならないよね、きっと。