Diary?

(23:36)

昨日の日記のちょっとした補足説明。テンプレートエンジンでのエスケープ処理を「テンプレート内でフィルターを使って行う」以外に「タグ付けを使って行い、テンプレートを書く側が HTML エスケープについて意識せずに済ませる」というやり方の可能性について書いたが、これら二つを同時に提供するつもりはない。何故なら前者はデザイナーが最終的な責任を負うやり方なのだが、後者はスーパーバイザーが責任を負うやり方だからだ。全く同じ事を目的とするのに別々のロールで別々のやり方があるというのは、どう考えても Caty の原理原則にはそぐわない。

いっちゃあ何だが、「A というやり方と B というやり方があります」みたいにオプションを用意して、それら二つがまったく同じ結果をもたらすというのは、想像以上に学習コストを上げる結果になる。なので Caty スクリプトの do 記法についても最初はかなり抵抗したんだが、「まあ檜山さんしか使わないだろうし、正式なチュートリアルからは外させよう」ということでギリギリ採用となった経緯がある。

インラインスクリプトとアウトオブラインスクリプトもかなりギリギリの判断で、インラインスクリプトが書けないとデザイナーだけでテンプレートの表示確認がやり難いだろうという事と、はっきりとした用途とワークフローを提示すればこれら二つがこんがらがる事はないだろうという仮説の元に導入していたりする（少なくとも俺は悩んだ）。

ちなみにそのうちリリースされる Caty プロトタイプのバージョン2では、以下のようなディレクトリ構成に固定して動作させるようにしている。ここで $CATY_HOME は Caty のアーカイブを展開した先で、 sites は個々のサイトを配置する先である。

$CATY_HOME/
           /python
           /common
           /sites
                 /<YOUR_SITE>

当初は $CATY_HOME 下以外のディレクトリにサイトやサイトの一部を配置させてもいいという仕様だったが、そういう事をやると弊害しかないのでユーザにとっては欠片たりとも嬉しくない。というか、前の会社で元々そういうディレクトリ構造の（アーカイブを展開した先に全データがある）某 ERP パッケージについて R&D していたときに、上司の趣味でディレクトリ構造に手を入れさせられた結果として開発したパッケージを配布するのが著しく困難になったという苦い経験があるので、この手のサイトの構造を野放図なレベルで柔軟にさせることには断固として反対だったりする。

このオプションを可能な限り制限するアプローチの例外の一つが複数テンプレート構文のサポートであり、これはそれぞれのテンプレート構文に（といっても Smarty 的文法と Kid 的文法で十分な気がするが）実用上のはっきりしたメリット/デメリットがあるし、既に知っているテンプレートの構文が使えるのは非常に大きなメリットなので採用する価値のあるオプションだ。