Ermitejo - エスペラント語日本語翻訳

Ermitejoの現在のシステム（といっても辞書引きくらいしかありませんが）は、HTMLテンプレートエンジンに、PerlのCPAN moduleであるところのHTML::Templateを使っています。

もう随分昔のことのような気がしますが、いや、むしろ事実として随分昔で恐縮なのですが、前回の記事で、Template-Toolkitに秋波を送っていました。その後、仕事の能率を上げるために自主的にJCLジェネレータの類を作ってみたり、ここでは書けませんが（Googleの20%ルールのようなものだと思ってください）しがないWebシステムの類を構築してみたりしました。

それらの活動は、趣味のプログラミング（このErmitejoです）にフィードバック出来るところがあるかなという下心も多分に含んでいたのですが、ともあれ入り口をかじってみるくらいのことは出来たように思います。結果、「物は使いよう」という、実に当たり障りのない結論に至ったわけですが、その感想を含めた評価は以下の通りです。

Template-Toolkit ～ 「なんでもあり」の強力なハンマー

特段の意識付けが不要な差し込み表示

HTML::Templateは文字列置換を基礎としたエンジンです。基本的な変数置換能力と、IF/ELSEなどの基本的な構文解析を提供します。一方、Template-Toolkit（package名はTemplateで、module名がTemplate-Toolkitです。TTとも略されます）は大変強力で、内部的にPerlコードを生成するために、色々な動作をさせることが出来る高機能なエンジンです。

機能は山ほどありますが、最も一般的な差し込み表示のための方法論を考えても、Perlで描いた複雑なデータ構造を容易に扱えるという優位点があります。つまり、ハッシュリファレンスや配列リファレンスを渡せるところです。HTML::Templateではいちいちparamメソッドでしこしこと使用データを定義してあげる必要がありますが、Template-Toolkitではこれが楽になります。

一次元の配列なら[% FOREACH foo IN bar %]で、N次元なら[% FOREACH foo = bar %]した内側で[% FOREACH baz = foo %]するといったように、普段扱っているPerlのデータ構造をまるっと渡しても、後は適当にテンプレートを描けます。

HTML::Templateではこうはいきません。自分でラッパを書くなど、やり方次第ではどうとでもなるのですが、それをしない場合には、paramメソッドが綺麗にまとまらず、あっちでしこしこ、こっちでしこしこと書く羽目になることもあります。

私の場合、「最後に描画して終了」する一般的な設計にしているため、クエリ格納用ハッシュリファレンスに描画用の各種リファレンスも足して、まとめて渡してしまうという荒技を採用しています。

CGIの場合、手の込んだことを使用とするとセッションを使って情報を持ち回りするのが王道でしょうが、さっくりと作ってしまう分にはhidden要素で持ち回る方法もまだまだ現役です。その点では、いちいちスクリプト側で定義をしなくても、必ずクエリハッシュを渡しておけば、テンプレート側だけで<input type=”hidden” value=”[% query.foo %]” />などと持ち回ることが出来るので、大変便利です。

より現代的にCatalystを使う場合でも、$c($context)をそのままTemplate-Toolkitにぶち込む方法となっており、表示クラスとの橋渡しをあれこれ考えなくていいのでとても楽です。

ただし、Ermitejo等々のように、プログラマと表示デザイナが同一人物である場合にはそれでいいのかも知れませんが、両職が別人であったりすると、分業の観点から考えるとよろしくないのかも知れません。何せPerlのデータ構造を渡せばよいというのは、即ち渡されるデータ構造を知らなければテンプレートが書けないことの裏返しなのですから。

何もかもテンプレートでやることでもない

勿論、薔薇色の未来ばかりではありません。やろうと思えば何とでも出来るというのは、やろうと思わなければいけないことを意味しています。Template-Toolkitは大分「こちら側」に歩み寄ってくれている感がありますが、例えばデータ構造自体が可変だと、すぐに条件文の嵐に陥ってしまいます。

具体的には、Ermitejoの例ですと、辞書引き結果のデータ構造体が挙げられます。動詞skribasにはあって名詞skribojnにないものとして「数」や「（表層）格」が挙げられますが、有無をいちいち判断して描画するしないを決めるのも無駄なテンプレートになってしまいます。

仕方がないので、「ハッシュ・配列が入り組んだデータ構造」を「表に適した二次元配列」に変換し、さらに「HTMLのtable要素」に変換するラッパを書いてもいます。

余談ですが、「表に適した」というのが曲者で、辞書引きの例だと列数を各行で同じにし、「値」を各行の最終列にしたり、空セルをcolspanしたりrowspanしたりと、あれはあれで少々手が込んでいたりします。

なお、名詞なのに「態」があったりと無駄のあるデータ構造をしていますが、本来ならないものと思ってください（く、苦しい……）。

Template-Toolkitでも、「テンプレートの中でPerlをeval出来る」という、それこそもうどこからどこまでがスクリプトで、どこから先がテンプレートなのかが曖昧となる素敵な機能がありますが、流石にそこまでTemplate-Toolkitと心中する気はまだないので、スクリプト側で実装しています。Ermitejoの辞書引き結果（上述のようにHTML::Templateを使っています）では、<table>～</table>までを一つのスカラに格納してしまって、テンプレート側ではそのtableを読ませるだけとしています。

今風なのでUTF-8での多言語処理も行ける口

Template-Toolkitは、多言語環境にも強いです。日本語話者を相手にするシステムを作る以上、文字化けは避け得ない問題なのですが、UTF-8という解がある限りは何とかなります。といっても、やっぱりINCLUDE/PROCESSした先のテンプレートがUTF-8で書かれていると文字化けするというお茶目なところがあったりします。うちはuse utf8; use open ‘:utf8′; use open ‘:std’;している環境ですので、Template::Toolkitでutf-8を使う(Lism.in * blog)という記事に助けられました。

HTML::Templateでは、多段読みをせずとも、単にUTF-8なテンプレートを読ませるだけでも文字化けしてしまいます。さっくり追ってみたところ二重エンコードしてくれるお節介が徒となっているところが分かり、「描画するのは最後の最後だから、もういいや」とばかりに、描画ラッパにuse binmode;を仕込んでしまっています。

動作が遅い

以上のように高機能なTemplate-Toolkitですが、当然のことながらその代償として動作速度を少々犠牲にしているところが残念な点です。描画させようとすると、軽めに作ったはずのテンプレートでも体感可能な（0.5秒程度で）遅延が見受けられます。

INCLUDEディレクティブの代わりにPROCESSディレクティブを使ったり、極力PROCESSを省いてみたりしますが、あまり効果はありません。そもそも共通部分を括り出そうとINCLUDE/PROCESSを使わないのは、テンプレートエンジン使用の大きな目的の一つを自分で捨てていることと等価です。無論、開発段階ではINCLUDE/PROCESSを使い、運用段階でそれらをまとめて、共通部分があり冗長になりますがINCLUDE/PROCESSを使わないという策もありますが、それを勝手にやってくれるような仕組みがないと手を出しにくいのも事実です。

なお、上記で「取り敢えずビール」とでも言いたげな「取り敢えずクエリ格納用ハッシュを全部渡すね」作戦を展開していますが、細かく「この変数名にこのハッシュリファレンスのこのキーを渡して……」と制御しても、軽くならない（むしろ制御が増えるだけ重くなる）上に開発生産性が落ちるので、これは諦めています。

もっとも、Ermitejoでない方のシステムはサーバとは名ばかりのWindows XP + IISという素敵な構成で稼働させており、それらを動かすハードウェアも単なる一世代前のPCで、性能が心許ないという点は考慮すべき点がありますが。

ともあれ、Webシステムのようにレスポンスが命であるものには、少々おっかない思いがすることも事実です。

mod_perlをApacheで動かすという、XREAやcoreserver.jpでは望めない案を試すことも考ましたが、基盤的な方面に手を伸ばすときりがないので、或る意味では考慮の埒外に置いていました。IISでもFast CGI(+ FCGI::IIS)が行けそうなのですが、まだ試していません。かなりの改善が見込まれそうなので是非手を伸ばしてみたいのですが、まずは非機能要件よりも機能要件という悪癖に伝染してしまっています。

結論：結局は使い分け

このように見て参りましたが、これまでの決して丁寧とは言えない評すらも擲って、一枚の表組みで乱暴に物を語ってしまうと、以下のようになります。

最後の比較軸は色物ですが、新鮮さや人気度合いというものはそのまま情報の入手容易性に跳ねてくるため、あなどれないものです。HTML::Templateの文字化けに悩まされた1年前は少々難儀したことを覚えています。

これらを総合的に勘案した結果、例えばJCLジェネレータは描画結果それ自体が目的なので、Template-Toolkitでゴリゴリ書くのが良いでしょう。多くの画面を要するウェブアプリケーションは、Template-Toolkitを使うのが楽ですが、自分でラッパを定義してあげればHTML::Templateでも十分役立ちます。Ermitejoの貧相な実装内容のように、あまり画面がないのであれば、なおざりなラッパでHTML::Templateを使っても問題ないですし、何より速さは正義です。

結局、アプリケーションの用途によって、つまり描画結果を作ることが目的なのか、描画結果はユーザインタフェースに過ぎないものとして割り切るのかによって、テンプレートエンジンを使い分けることが大事なのかも知れません。何とも玉虫色の結論ではありますが。一応、Ermitejoの開発中のバージョンではTemplate-Toolkitに乗り換えていたりします。