PEAK XOOPS - あまり知られていない(?)Smartyフィルターの利用法(3)

Modifierに任意の関数が使える機能は、Smarty自体、かなり昔からサポートしています。新規の案件でSmartyを使うならもちろんのこと、XOOPS用モジュールとしてリリースする場合でも、そのバージョンを気にする必要はありません。

ただ、$smarty->security という制限があることだけは知っておく必要があるでしょう。これはプロパティなので、いつでもON/OFFできます。

プログラム中のコメントにもこのように書いてあります。

ただこのコメントはどうかと思います。
信用できないパーティーにテンプレートを編集させる時点で、すでにアウトです。
{php}ブロックとかの利用を制限したとしても、最低限、Script Insertionはあります。

むしろ怖いのは、権限を持つ人間がテンプレートを書かされてしまうことでしょうか。
つまりXSS+CSRFです。その可能性を考えれば、$smarty->security ONで、CSRFの即任意コード実行、という状況がなくなることはメリットと言えなくもありません。

$smarty->security がONの場合、通常関数をmodifierとして利用するには、$smarty->security_settings['MODIFIER_FUNCS'] に利用可能な関数を登録する必要があります。どうしても、デザイナー側の機能を制限したい、という向きにはこれを利用すると良いでしょう。

さて、tohokuaikiさんからこういうコメントを頂戴してます。
Quote:
いえいえ。私自身が考えるSmartyの利点は、分散開発を容易にすることです。
XOOPSなんかはまさに分散開発ですよね。コアはコアで、モジュールはモジュール毎で、各サイトは各サイト毎で、それぞれ独立して開発できる。

そのためには当然レイヤーという概念が必要です。
そして、各サイト製作者にとってのレイヤーがテンプレート（テーマ）なんです。
カスタマイズで、PHPをいじってしまうのでは、コアやモジュールとモロに競合します。
だからこそ、「テンプレートでいろいろやってください。関数だって自由に使えますよ」なんていのうが、まさにメリットになるわけです。

もともとView層のみだったはずのPHPに、Smartyという上位View層があって、そこでもロジックをいろいろいじれる、なんていうのは不思議に見えるでしょうが、XOOPSではサイト製作者のレイヤーとしてうまく機能しているんです。tplsadminの登場以来、ますますその性格が強くなっていると思います。

よって、プログラマー（モジュール作者）がデザイナー（サイト製作者）の機能を制限するなんていうのは傲慢だと考えています。