面白いから作る！ PCホビイストの開発体験談：Windows Liveが魅せる次世代マッシュアップ（6/6 ページ）

[川俣晶，ITmedia]

　さて次は、実際にコーディングを行った開発環境だが、実はVisualStudioはほとんど使っていない。ほとんど、秀丸で書き換えを行った。この程度の書き換えであれば十分である。慣れないVisualStudioを使うのに抵抗があるならば、使い慣れた愛用エディタで記述するのも1つの選択肢である（ちなみに、筆者は長年VisualStudioを使い込んできた熟練ユーザーだが、こういう書き換えには軽いテキストエディタを好んで使っている）。

完成したLiveガジェットの公開には

　完成したLiveガジェットは、Windows Live Galleryサイトに登録することで、全世界から見てもらうことができる。

画面4■Windows Live Gallery

　登録するために必要なものは2つある。

　1つは、Windows LiveのID。Liveガジェットで遊ぼうと思う人なら既に持っていることだろう。持っていないとしても無料ですぐ発行されるので、手に入れておこう。

　もう1つは、登録用のガジェットのパッケージである。要するに、ガジェットに必要とされるマニフェスト、スタイルシート、JavaScriptソースをZIP圧縮すればよいのだが、注意点が2つある。

　1つは、マニフェストのファイル名をgadget.xmlに変更しておくこと。SDKのサンプルソースは、いずれもこの名前になっていない(RssGadget.xmlのような名前になっている)ので、注意が必要である。

　もう1つは、マニフェストに書かれたURLを全て相対URLに書き換えることである。

　たとえば、ITMediaHeadlines.jsファイルをマニフェストと同じディレクトリに置くとき、

<link>http://localhost/Gadgets/ITMediaHeadlines/ITMediaHeadlines.js</link>

　というテスト用のホスト名とディレクトリを含む記述は、以下のように書き換えねばならない。

<link>ITMediaHeadlines.js</link>

　さて、以上の注意点を反映したZIPファイルができたら、さっそく登録だ。Windows Live Galleryのホームで、Gadgetを選び、それによって表示されるページで"Galleryに登録"を選ぶ。

画面5■登録情報の入力

　あとはタイトルやカテゴリなど、必要な情報を書き込む。ファイルは、直接自分のPCからアップロードするなら、「コンピュータからファイルをアップロードする」を選ぶ。すると、「ファイル名」の欄の後ろに「参照」ボタンが出るので、これをクリックしてZIPファイルを選択する。

　最後に、「使用条件に同意します」のチェックを入れて、登録ボタンをクリックする。

　この段階で、仮承認として受理される。

画面6■仮承認段階

　正式に登録が受け付けられたかどうかは、後日、電子メールで通知される。ファイルに不備があったり、利用規約に反していると却下されることもあるので、間違いがないことを祈りして待とう（筆者は、マニフェストファイルの名前を変え忘れて却下を1回食らってしまった。めげずに……）。

画面7■却下されたときのメール文面

画面8■登録が通ったときのメール文面

　ちなみに、返送されるメールの内容はクセがあるので注意が必要だ。まず、これはシングルパートのHTMLメールとして送信される。

　HTMLメールを扱えないメールソフトでは正常に読むことができないかもしれない。また、電子メールヘッダーではISO-2022-JPが指定され、内容もISO-2022-JPで記述されているにも関わらず、HTMLのヘッダーに以下のようなUTF-8を指定するmeta要素が入っているため、文字化けが起こる可能性がある。

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

　もし、文字が化けて読めない場合は、手動でエンコードを日本語(自動選択)などに切り替えると良いだろう。

　実際に登録された今回のサンプルソース、ITmedia Enterprise Headlinesは以下のURLに存在する。

http://gallery.live.com/liveItemDetail.aspx?li=400a6e6d-abfa-4f20-8fda-f57ad52026e2&l=1

画面9■登録されたITmedia Enterprise Headlines

　ここより、プレビューを選ぶと動作を見ることができる。live.comに追加を選ぶと、そのままWindows Liveのポータルページに配置して利用可能になる。

オラ、わくわくしてきたぞ

　以上で今回の話は終わりになるが、最後に1つだけ付け加えておこう。

　Liveガジェットは、表示される中身をいちいちDOM APIを使って組み立てねばならないため、WYSIWYGのHTMLエディタなどでデザインを作ることが難しい。これはどう考えればよいのだろうか？　理不尽な制約だろうか？　それとも、あえて困難なやり方を開発者に提示してやる気のある人材を選別しようとしているのだろうか。

　私はどちらでもないと思う。

　あくまで印象を語っているに過ぎないが、おそらく、ドキュメントに含まれるノードの誕生と消滅を逐一厳密にフレームワークが把握するために、このような構造を取っているのではないかと感じた。

　例えば、今回のサンプルソースで、表示するフィードを切り替えるボタンを押すと一時的にフィード内容が消えるが、その際、自動的にガジェットのサイズが小さくなり、下に表示されたガジェットがなめらかにせり上がってくる。もちろん、自分自身のサイズを変化させるであるとか、下のガジェットを移動させるであるとか、そういったコードはいっさい記述していない。それは、ガジェットを配下で実行させているフレームワークが自動的に采配してくれるのだろう。

　つまり、Liveガジェット開発とは、フレームワークが要求するさまざまな課題をクリアすることで、フレームワークと愉快な共犯関係を成立させることではないだろうか。

　ここまで来ればもう結論は間近だ。WYSIWYGのHTMLエディタで静的なデザインを作ることなど考えても意味はない。ガジェットに与えられた限られた表示面積を活用するために、変幻自在にDOMノードが生まれては消えるダイナミックな画面を実現してこそ、Liveガジェットの真価が発揮できるというものだ。

　あえてHTML文書を直接書かないでプログラムで組み立ててみせる渋いやり方には、そういう潜在価値が眠っていたのではないだろうか。

　そう考えると、ワクワクしないだろうか？

---

　オンライン・ムックPlus「Windows Liveが魅せる次世代マッシュアップ」では、“Liveガジェットのアイデア募集”を行っている。読者から寄せられたアイデアは、本特集上で優秀作やアイデア傾向などを紹介していく予定だ。