イベントハンドラの実装

イベントハンドラの実装

　FREDDYデータの受信は、SAXと同じようにイベントハンドラを介して行う。ハンドラのコードは図2（上）のようになる。

　コードを見ると気がつくかもしれないが、JavaのSAXで使うイベントハンドラとほぼ同じコードである。

　「第2回：JSONPとFREDDY（http://www.thinkit.co.jp/article/116/2/）」で紹介したFREDDYフォーマットの関数呼び出しは、データサイズ削減のため、sやeのような短い関数名を使っていた。この関数呼び出しをFREDDYライブラリ内で受けて、startElement、endElementのような、可読性の高い関数名へリダイレクトしている。

　また、FREDDYはxmlからFREDDYへの変換ツールを提供し、さらにクライアント側のコードはSAXとほぼ同じである。つまり、SAXを使ったプログラミングの経験があれば、FREDDYフォーマットや、後述するWebサーバーとWebブラウザ間通信の仕組みを理解せずとも、大規模なデータを使ったWebアプリケーションを実現することができる。

ハンドラの裏で何が行われているか

　ここからは、FREDDYの内部的な動作について説明していく。と言っても、そんなに複雑なことをしているわけではなく、基本的にはDynamic Script Tagを使って各Pageを順に読み込んでいるだけだ。

　図2（下）はFREDDYの動作原理を示している。この図ではxml2freddy.xmlをゲートウェイとして利用し、実行時にXML文書から直接FREDDYフォーマットへ変換し、それを読み込んでいる。

　FREDDYによるデータ通信のポイントは、Dynamic Script Tagによる非同期通信を使ったデータの読み込みと、イベントの送出をほぼ同時に行う点である。

　「第2回：JSONPとFREDDY（http://www.thinkit.co.jp/article/116/2/）」のFREDDYフォーマットの分割を説明した個所で、各Pageの先頭にはnp(PageID, “URL”);という次ページへのリファレンスを記述すると説明した。実はこのコードは次PageをDynamic Script Tagで読み込むための関数を呼び出している。

　つまり、あるPageを読み込むと、最初に次Pageを読み込むリクエストを非同期で発行し、その後、Pageに含まれたイベントをハンドラへ通知している。分かりやすく例えるなら、今、読んでいるこのページを読み始めると同時に、次ページの記事を別のタブとして開いているようなものである。このページはあと数段落で読み終わるが、すでに次のページが読み込まれているので、通信による待ち時間無しに次のページを読み始めることができる。

　また、XMLファイルからFREDDYへの変換も動的に行うことができるので、図2（下）に示したように、XMLの読み込み開始とほぼ同時にFREDDYを介して、そのXML文書のSAXイベントを、Webブラウザ上のイベントハンドラへ届けることができる。この仕組みにより、SAXの特徴である「高速な動作」を、Webアプリケーションでサーバー上のリソースを読み込む場合でも実現することができる。

　次のページでは、同じくSAXの特徴である「低消費メモリ」をWebアプリケーションとして実現する仕組みについて説明する。