また Extension の対応が変わった。いちいち変わりすぎ。もう少し考えて作れないのかな。Extension 作者、Theme 作者もよくいやにならずに追随してくれるよ、ほんと。というわけで使えない Extension がまだまだあるので 1.0 PR はやめにした。Security Fix なら 0.9.4 出してくれればよかったのに、まったく。

Mozilla Seamonkey の動きを見ればきっと 1.0 以降も似たような話は絶えないだろうなって感じがするけど、Firefox の成否のカギは Seamonkey から何を反省したかってのもかなり大きいと思う。

例えば Extension は Firefox を使ううえでのキモみたいなもの¹なんだから、もう少しうまく扱えるようにすべき。Extension の仕様は分かっているんだから、インストーラの段階で対応しているかどうか調べられる仕組みを作れないのか。（簡単ではないと思うが。）

そして Security Fix をどこまでバックポートするかというのもきちんと判断する必要があるだろう。Firefox が単なる Technology Preview でなく Mozilla Foundation の Product という位置付けになれば、非互換の部分がたびたび発生するのはまずかろう。これが単なる Extension でなく業務に使えるレベルの XUL アプリだったらどうする。Security は気になるが XUL アプリの対応ができていないからアップデートできない、ってことだって十分にあり得る。それじゃ IE と同じだ。Microsoft 様と同じことを弱小 Mozilla Foundation がやったらそりゃ勝ち目なんかない。

今回の方法（0.9.4 ではなく 1.0PR をリリース）が 1.0 ゆえの緊急避難であったことを望む。

あ。Extension および XUL アプリのアップデートチェッカが Firefox に依存せずに単独で動くとだいぶいいかも。少なくとも Extension が対応してなかったからアンインストール → profile 飛ばし → ダウングレードインストールの流れは要らなくなる。まーでも security fix はある程度バックポートするってのがまず基本じゃないのかな。

• 思ったより情報が少ない
• CPAN にはたくさん登録されているが、FreeBSD の ports, Debian package で探すと以下の3つしかない。¹perldoc.jp にも以下の2つしかない。
  • HTML::Template
  • CGI::FastTemplate
  • Template(template-toolkit.org)

HTML::Template

• 独自タグ <TMPL_VAR> を使う
• HTML タグの中に HTML タグを書くことになるのだが、エディタで見ている場合はともかく、WYSIWYG ツールには優しくない気がする。
  • 特に顕著なのは属性の値をこれで与える場合。NAME="VAR" の "" は書かなくてよいので、そういうルールで運用しておいた方が無難。²
• 内容をセットしない変数の部分は出力されない。この動作はいい。
• このモジュールで output() しても実際には STDOUT には出力されない。結果が返ってくるのでそれを print する。なんか意外な動作。
• テンプレートの中にロジック入りまくり。

<TMPL_LOOP>
<TMPL_INCLUDE>
<TMPL_IF>

こういうテンプレートの方が人気が出るが、これはテンプレートの役割として謳われているロジックとデザインの分離が果たされていないということをみんなあえて無視しているんだろうか？ つーか文法が2つもあったら邪魔くさいじゃん。文法は Perl だけにしようよ。

キャッシュはあるが、HTML::Template::JIT を使うとさらに高速化できる。ただし、コンパイルは遅い。

CGI::FastTemplate

Fink には入ってなかった。

• 変数は Perl の文法に従い $VAR と書く
  • 正確には以下の正規表現にマッチするものに限る。（UPPERCASE に限るってちゃんと perldoc に書いてほしいなぁ。）

/\$(?:([A-Z][A-Z0-9_]+)|\{([A-Z][A-Z0-9_]+)\})/

• 内容がセットされなかった変数の部分はそのまま $VAR と表示される
• HTML である必要はない
• 正規表現でパースしている
  • man では eval を使っていないから速いという話
  • 単純な正規表現パースなのでテンプレートにロジックを入れられない（Good!）
• CGI 用に content-type ヘッダを自動で出力はしてくれない
• strict() メソッドで parse エラーを STDERR に吐き出すことができるので、Web サーバのログを利用しながらテンプレートのデバッグができる
• if や loop などのインテリジェントな機能はない（テンプレートにロジックが書けないだけじゃなくて、そもそも機能としてない）
  • loop は苦肉の策で loop 部分だけ別のテンプレートに分割してそのテンプレートの parse 結果をスクリプト内で loop して連結させるという方法を採る。loop の数が1つだけならいいかもしれないが、list 1つ、table 2つとか言うテンプレートになるともう扱いがかなり面倒な気がする

本格的な運用には難しいような

template-toolkit.org

かなり柔軟な処理ができるらしい。

CGI には限らず使えて、変数は　[% var %] で書く。INTERPOLATE オプションをつければ $var と書ける。（FastTemplate と違って小文字で ok）

• 変数名はブロックの単位でハッシュ変数を割り当てるとかなり分かりやすいものにできる。
• ハッシュのハッシュでも ok
• [% %] の記述であれば、という制限がつくと思う（まだよく分かっていない）が、テンプレート内に制御構造をバリバリ書ける。
• 考え方によっては [% %] でループなどのブロックを、$ で変数を書ければよかったんじゃないかなぁと思うんだけど、どうもそうはなっていないらしい。
• 個人的には独自タグ方式よりまだマシに見えるけど、まだテストが必要ですな。

条件を理解するのがむずい。

userdir の場合に限定すると、

• 対象となる CGI およびそれが収まっているディレクトリの owner が本人
• またそのディレクトリおよびファイルが owner 以外に +w になっていない

ことが条件。

user の部分以外は 6 以上の permission（writable）は許可されない。

755 とか 644 かそれ以上に厳しい permission にしなさいと。module mode の PHP に慣れちゃうとつい忘れる。¹つーか Apache.org の配布では標準では disable なのよね、これ。Debian がデフォルトで enable になってるから戸惑ったのか。複数の環境を使うのって勉強になるな。

module mode の PHP では

secure mode を設定する。secure mode はどの程度 secure にするか細かく設定できるので、例えば普段の開発は緩めに、動作検証ではきつめになどの設定変更が可能。まぁそれ言ったら Apache の設定次第で CGI の動作も変わるんだから同じっちゃ同じなのか。開発環境は普段 suExec が disable の方が使いやすいのかもな。

書けるらしい。

まぁどっちみち Python 依存なんだけど。