XML が基本ツールとなってから、もう久しいわけですが、私なんかだと一番最初に「XML....勉強しなくては！」（1999年くらい？）となって読んでたりしたのが、XSLT の本だったりします（ちょっと変？）。今考えると、これが「役に立つ！」局面はなかなか簡単に来なかったのですが、最近は少し風向きが変わってきたような気がします。

というのは、例の Ajax で、JavaScript で DOM を解析する面倒さから逃れたい...というのがあって、「前もって XSLT で（簡単なものに）変換しておいて、それから解析」という手順を採用している、というのもあるわけです。まあ、昔勉強したのがやっと役にたつようになってきて喜ばしい限りですが。

とはいえ、XSLT でややこしいのは XSLT 自体というよりも、「XPath の指定法」である、というのは皆さんもお気づきでしょう。XPath の表現力はかなり高いですから、いろいろと細かい指示を書くことが出来てしまいます。

...で、最近、面白がって触っているのが、Xindice だったりします。これは Apache XML プロジェクトで開発されている、「XMLデータベース」です。つまり、データの単位は XML ドキュメントがそのまま格納され、検索単位は個々のエレメントでも何でもＯＫ！という次世代的データベースなのですが、「検索する時、どうやって指定するの？」というのが、SQL ではなくて XPath なんですね。

まあ、これは当然です。XML の上でのどんな要素でも、ちゃんと指定して書ける書き方、として XPath が策定されているわけですから、XSLT だろうと XML データベースだろうと、「XPath なしでは...」となるわけです。

私が前にハックした、Log4j でも開発中バージョンでは、設定ファイルを解析するのに DOM ではなくて、「XPath でパターンを指定し、アクションと結びつける」という先進的なアイデアに基づいた JoranConfigurator で設定ファイル解析がされていたりします。そういうわけで、「XPath の教養」というのも、今から重要になってきそうな....気がします。

最近、レガシーな Web アプリ開発でも、Ajax を機能として取り入れよう...というのが、かなり具体的な案件として出るようになっています。本流の遷移は通常の POST メソッドによるレガシーな遷移で行うが、たとえば、「一覧表のソート順変更」「検索条件の変更」といった処理は、ＵＩとしては重要ですが、処理の流れとしては副次的なものとなります。そういう副次的処理を Ajax 部品に任せてしまう、としたら、流れが理解しやすく、メンテも楽なコードになることでしょう。

この時、重要なポイントがあるように思います。それが実は、REST と同じ結論になるので面白いと思うので書きましょう。「REST って何？」という方もいるでしょうが、これ最近かなり流行ってる Webアーキテクチャ・スタイルです。「REST ＝ SOAP や XML-RPC ではない簡単な Web サービス」というお考えの方もいるかもしれませんが、そういう方は定評のある山本陽平氏の「REST入門」をお読みになることを薦めます。この REST のポイントを乱暴にまとめてしまうと、

1. リソースは URI で特定する→だから PathInfo からリソースIDを拾い出すことが多い。ブログの permalink はこのやり方。
2. GET, POST, PUT, DELTE の「動詞」が HTTP では用意されているのだから、それを「正しく」活用する。GET はリソースの状態に影響を及ぼしてはならないが、POST はリソース状態の新規作成に限って使われなくてはならない。既存リソースの状態の変更は PUT メソッドだ。
3. URI情報はリソースを特定するためにあり、見かけの制御はクエリ文字列の担当にすべきである。→ URI はクライアントで操作すべきではない。（ＵＩを通じて）操作すべき対象はクエリ文字列に限定すべきである。
4. クッキーを使ったセッション管理は、HTTP 以外で状態を持ち込むから、REST ではない。REST はステートレスである（状態を内部で持たない）。

といったあたりが重要なポイントでしょうか。まあ、勿論レガシーな Web アプリはこの原理に従っていないのが普通でしょう。Webアプリ＝セッション管理付き、というのがこれまでは常識でしたし。ですから、REST がそのまま既存の Web アプリのすべてに革命的な影響を与える...とまでは言えないものなのですが、それでもアイデアとして気に留めておいた方がよいポイントがあるように思います。

それは、

「GET と POST のメソッド、クエリ文字列とコンテンツのパラメータを意識的に使い分ける」

ということです。<form> を使うと、とにかく POST メソッド！という感覚でリクエストすることになってしまうのですが、その時に「リソースの特定（たとえば dataId）」も「表示オプションの指定（たとえば display_order）」も「更新動作のコンテンツ（たとえば contents）」もすべて POST パラメータに突っ込んで、POST のリクエストを発行してしまいがちですが、これはもう少し意識的になってもよさそうです。

<form method="POST" action="/hogehoge/some">
<input type="hidden" name="dataId" value="13"/>
<input type="hidden" name="display_order" value="1"/>
<input type="text" name="contents"/>
<input type="submit" value="GO"/>
</form>

たとえば、表示のみならば、

<form method="GET" action="/hogehoge/some/13?display_order=1">
<input type="submit" value="GO"/>
</form>

というかたちでの書き方があるかもしれません。「POST を GET にするメリットなんて...」と思われるかもしれませんが、実はこれがあるのです。

Ajax を使っていろいろやっていると、妙なことに気づきます。それは、XMLHttpResponse() の挙動が、POST と GET で違う、ということです。GET メソッドで発行した時には、リクエストがキャッシュされて、実際のリクエストが飛ばないことがあるのです。これは要するに、「GET メソッドは状態を変えないアクセスだから、結果をキャッシュしてもかまわない」という原理でライブラリが書かれている、ということです。逆に POST メソッドは一切キャッシュされません。つまり、「状態を変更するのならば、POST でないと正しく動かないことがありうる」というのが、Ajax の前提なのですね。

同様の動作をプロキシがする可能性もあります。普通は POST メソッドでのリクエストを主体に Web アプリは書かれますから、「常にキャッシュなし」で動くことになります。このモデルは「何か操作をして、その結果を見て」の連続で動作する Web アプリの操作と相性がいいのですが、「見られる専用の部分」を GET メソッドで取得するようにすれば、キャッシュによってパフォーマンスが改善される可能性があります。

また、これは特に Ajax を副次的な機能として使う場合に重要ですが、「この操作の流れの中でデフォルトなパラメータ」と「一時的に何かをさせるために与えられたパラメータ」を積極的に区別すれば、「完全な表示状態」をクエリ文字列から取得できることになります。Ajax で副作用のある処理をさせた後に、表示の更新をかけたいのならば、単に「自分が呼ばれたURI」をそのままキックすれば、Ajax による副次的な更新結果を反映した表示を得ることができるようになります。リクエストパラメータの再構築とか、そういうややこしい処理は一切なしで、単に環境変数から QUERY_STRING を取得してそのままリクエストすればいいだけなのです。<form> を入れ子にできない制限から、副次的なフォームをメインのフォームの外に追い出して、JavaScript でパラメータをセットして叩く、というような可読性の低い処理とはおさらばしたいですよね！

というわけで、Servlet では「メソッドの種類を問わないように抽象化するので、そのパラメータがクエリ文字列出身なのか、リクエストのコンテンツ出身なのかは気にしない...」というのが当り前になった後で、これを再度区別するメリットが出てきているように思います。

ブログを書くっていうと、管理画面にログインして...って人も多いでしょうが、いわゆる「ブログツール」を使っている人も多いんじゃないでしょうか？ で、私もそういう「ブログツール」を使おうか....とテストしてみたことはあるんですが、どうも気に入りませんね。

その理由は、「○○のブログに簡単に投稿できる、Windows（なんか）のスタンドアロンアプリ」という点です。まあ、それは勿論、「便利ツール」ということで、そういう設計に文句がつけたいわけじゃないです。が、たとえば、「自分が開発するブログ系サービスに、特殊なＡＰＩを作ってやって、それをテストしたりするのに使える、どういうリクエスト＆レスポンスが飛んでいるのか一目瞭然で判り、特殊なＡＰＩ用だって追加できるような開発ツール」というノリのものが欲しかったりもするわけです。

でこれにちょいとアイデア。「どうせなら、HTMLベースで、Ajax を使い倒してリクエストを出す」ってどうですか？　勿論 Ajax には「同じホストでないと XMLhttpResponse() のセキュリティ制限にひっかかる...」という問題があったりします（ＩＥはいい加減ですが）。が、自分のブログ開発用だったら、それは全然問題にならないわけですし、すべてクライアントサイドですから、プロキシＣＧＩを運営しちゃう危険性もないわけです。

というわけで、俄然やる気になってます。近々、それもお披露目できるのでは？と思ってますのでお楽しみに！

この「あすなろブログ」は、大勢に合わせて MovableType なんですが、仕事で使ってみたのは実は Blojsom なんですね。「Java のウェブアプリと連動して...」という前提があったので、「Java で書かれたブログ・アプリって何があるだろう？」と調べてみたら、やはり Perl or PHP が多いのですが、それでも４つばかりあります。

Apache のインキュベーター・プロジェクトには Roller があり、日本語リソースがあるという点では Pebble があります。が、私が気にいったのは、Blojsom なんですね。これは Blosxom って有名な Perl のブログ・アプリがありますが、その Java 版みたいな感じで開発されたもので、アイデアをいろいろと Blosxom から引き継いでいたりします。私の萌えポイントは、実はこの Blojsom が「何でもプラグイン！」という強烈な思想で設計されているあたりだったりします。

フツーはブログは「管理画面を担当するCGI（とか)」と「普通に見る画面を生成するCGI（とか...MovableTypeは再構築でHTMLを作るのがデフォルトですが）」が分かれているものですが、実は Blojsom は「管理画面」さえも同じサーブレットの別フレーバーで、プラグインを駆使して作られていたりするわけです。

能力的には最新版の3.0では、データベースにブログデータを保存するかたちになっていますし、まだあまり3.0用は整備はされていませんが、スキンに相当する画面デザインも充実してくることでしょう（2.x版はいろいろありますが....）。というわけで、私は Java 主体なこともあって、ちょいとコレ、買いです。

そんなこともあって、私が個人で書いているホームページ に、「Blojsom Hack Guideというページを書きつつあったりします（まだ途中ですが...）。そちらも関心を持たれた方はどうぞ！

皆さんはじめまして。このたび「あすなろブログ」に参加させていただくことになりました杉浦といいます。

今私はパソナテックからの派遣で、大阪のソフトハウスで働いています。業種は Java のウェブアプリ系プログラマです。最近 Web2.0 というコトバが流行しているわけですが、その仕事では比較的自由が効くので、「Web2.0」ネタをいろいろと活用しよう！ということで、日々いろいろと書いています。

そんな生活の中から、Web2.0 活用ネタをいろいろお届けしようというのが、このブログの目的です。Java に限らずいろいろと紹介していくつもりですので、ぜひぜひご愛読くださいませ！