WebアプリとHTA

Webアプリで作ったデータをローカルPC(Windows)で動いているシステムに取り込みたいとかいう話なんですが、普通に考えれば、Webアプリ側にAPIを用意してローカルのシステムでHTTPをお話するという方法がマットウに思えますが、結構面倒くさい方法ではあります。


で、別のアプローチ。

案1

ローカルPCのHTAでiframeでサイトを開き(HTA)、欲しいデータを表示するページからデータを抽出して(JavaScript)、ローカルのシステムに渡す(WSHっていうかActiveX)。
HTAのコンテキストからiframe内のDOM要素にアクセスするための方法はこんな感じ。

var frame = $("<フレームのid>");
var frameWin = frame.contentWindow;
var frameDoc = frameWin.document;
var some_element = frameWin.$("some_element_id");

prototype.jsの$関数もframeWinに対して行うことで利用できます。
また、frameDocに対してcreateElementなどもできるのでページを、ローカルシステムと連動しやすいようにページを作り変えることも可能。でも、やってみて思いました。IFRAMEの内外でコンテキストが違うのが、面倒くさいです。それにIFRAMEの外のコンテキストから中のコンテキストにアクセスするのは、FirefoxなどではPermissionDeniedになってしまいます。デバッグしにくい!

案2

で思いついたのは、HTA内でIFRAMEを使わずに、HTAで利用されることを想定したコードを含んだHTMLフラグメントをWebアプリが返すようにして、HTA内ではAjax.UpdaterなどでWebアプリの用意したHTMLフラグメントをゲット。
IFRAMEを使わないため案1よりもJavaScriptのコードは簡単です。でもWebアプリ側に手を入れられないとダメですね。
で、HTMLフラグメントというと、サーバーのアプリを通さなければならないような気になってしまいがちですが、静的なHTMLフラグメントをサーバー上に置いておくだけでもかまいません。その方が楽ちんな場合もあると思います。

まとめ

HTA側とWebアプリのどちらを変更しやすいかで、アプローチは変わると思うんですが、前者の方がクライアント側のみでゴリゴリとハッキングという感じで結構好きなノリですが、後者の方がスマートだしメンテが楽にできると思います。なので、Webアプリに手を加えることができるなら後者を採用し、例えばRailsアプリならビューをHTMLフラグメントを返しやすいpartialにして適当なコントローラにそのpartialなビューをレンダリングするアクションを作ってあげればOKだと思いました。


なんかApolloが流行りそうだから今更って感じもするけど。