EthnaでSmartyの設定値を直接ごにょごにょしたい場合

EthnaでSmartyのキャッシングしないようにするのはどこで設定すれば良いんだ？

http://twitter.com/nuffy/status/1155200551

うちではこんな方法で書き換えてます。

app/[APPID]_Controller.php にメソッドを追加してオーバーライドする

<?php //色づけ

    /**
     *  テンプレートエンジンのデフォルト状態を設定する
     *
     *  @access protected
     *  @param  object  Ethna_Renderer  レンダラオブジェクト
     *  @obsolete
     */
    function _setDefaultTemplateEngine(&$renderer)
    {
        $backend =& $this->getBackend();

        if (strtolower(get_class($renderer)) == "ethna_renderer_smarty") {
            // Smarty設定
            // 閉じ、開始を<{ }>に変更
            $renderer->engine->left_delimiter  = "<{";
            $renderer->engine->right_delimiter = "}>";
            // SmrtyConfigLoad
            $renderer->engine->config_dir = $this->directory['etc'];

            $renderer->engine->autoload_filters['pre'][] = 'exchangelink';
            $renderer->engine->autoload_filters['pre'][] = 'delimiter_urldecode';
            $renderer->engine->autoload_filters['pre'][] = 'ssiparts_include';
            $renderer->engine->autoload_filters['pre'][] = 'replaceword';
        }
    }

こんなん

perform()のreturnの書き方によってEthna_InfoManager内で無限ループが起きる

昨日、Ethnaのコミッターの mumumuさん、id:sotarokさん、id:ichii386さん、他にもEthnaを実際に開発で使用しているという方々と総勢7名で焼肉食べながらEthnaについていろいろ話し合ってきました。
Ethna 焼肉会議 議事録

Ethna 焼肉会議を開催します - 肉とご飯と甘いもの @ sotarok
肉mtg - いちいの日記
mumumuの日記: Ethna Yakiniku-Con
などなど。

で、Ethnaが今後、どのようになっていくのかは、まだわかりませんし、新しく始める人は他のフレームワークを選ぶかと個人的には思ったりして、それでもEthnaを使っている理由って何だろうなんて考えたりしながら二日酔いの中仕事をしていました。
Ethnaを使う理由のひとつに、開発者が全員日本人というのも利点の一つとしてあるのかなぁと思ったりもして、日本語でバグ報告とか、こうしたいと言えば、がんばって辞書と格闘して英語を書かなくても通じるというのは、いいことだったりするのではないかと。
もちろん、日本内の狭い世界に閉じこもってしまうとうことになったりもしますが、だったら逆に、日本の携帯への親和性とか、いろいろアプローチもあるのではないかと思ったりもしてみました。

で、バグとかやりたいこととかがあがってきた時に、すばやく柔軟に対応が出来ればいいなーと思って、現状の報告経路をながめていたら、SourceFoge.JPのバグで放置しっぱなしのがあったので、さすがによくないと思い、最新版で再現するかを確認してみました。
指定された対象が見つかりません - SourceForge.JP
再現したので、パッチ書きました。
Ethna_InfoManagerはテストが無く、しかも処理が複雑なので、ちょっと自信が持てないので他のコミッタの方の意見待ち中です。

http://maru.cc/~maru/ethna/ethna_infomanager/Ethna_InfoManager_analyzeActionScript.patch

しかし、ソースを追ってみて、知らない関数にであったり、知らない定数があったりとか。
PHP: token_get_all - Manual
PHP: パーサトークンの一覧 - Manual
まだまだ、知らないことがありますね。

しかも、info.phpの一覧を出すために、構文解析っぽいことをしているとは思わなかった。
すげー力技だけど面白い。

events.php.gr.jpに手を入れた

PHP勉強会などの告知、募集を行う http://events.php.gr.jp のシステムにちょっと手を入れてました。
以前は、Ethnaで出来ていたこともあり手をいれやすかったのですが、CakePHPになりしばらく中も見ていませんでした。
今回、管理者側機能の修正関連で落として自分の環境で作成をしていろいろテストをしてみました。

いろいろ触っていたら、nicknameにタグが入れられた場合にエスケープ処理がされていなかったので修正とかしたりとかしてました。
http://coderepos.org/share/changeset/28857

テンプレートファイルが拡張子が *.ctp ってのに驚きました。
CakePHPでは普通なんかな？
何か機能を足したい、ここを修正したい。みたいな目的があると、同じソースを追うという作業をしても身になるなぁと思いました。
人のソースを見るのは勉強になる。ましては、普段使っていないフレームワークとか面白いです。

他にも足したい機能とかあるので、ぼちぼち触っていこうかと思います。

Ethna_ActionForm_Testがこけていたのを直した

以下の記事で書いていた、ActionFormのテストが環境によってこけていたのを直しました。
Ethna本体のテストが環境によってこける - maru.cc@はてな

直接の原因はCsrfのプラグインのテストが、テストで変更した値を元に戻していなかったということと、ActionFormの初期化処理中に $_SERVER['REQUEST_METHOD'] の状態によって挙動が変わるのをテストに書かれていなかったというもの。

• Diff of /ethna/trunk/test/Ethna_ActionForm_Test.php - Ethna - SourceForge.JP
• Diff of /ethna/trunk/test/Plugin/Csrf/Ethna_Plugin_Csrf_Session_Test.php - Ethna - SourceForge.JP

テストを書くときに、前処理、後処理が漏れていたりとかして、テストの順番に依存してしまう場合というのは、なかなか気づきにくいですね。。。

Smartyプラグイン関連をコミットした

以下の記事で書いていた Ethna組み込みの Smartyプラグインを Ethnaの本体へコミットしました。
EthnaのSmartyプラグインを独立したファイルにしてみた - maru.cc@はてな

勢いで分割したのが12月頭なので、ずいぶん遅いですが。。

これで、Smartyプラグインの追加が気軽に出来るようになったかと思います。
仕事で使っていて有用そうで汎用性があるものは、Ethna本体に入れちゃっていきたいと思ってます。

最近のテンプレートは素のphpで書く phpテンプレート形式がはやってますが、EthnaはSmartyべっちゃりなところもあるので、まずは。という感じでしょうか。
今後は、phpテンプレート形式も含めて、他のテンプレートエンジンを公式にサポートさせていきたいです。

Ethna本体のテストが環境によってこける

Smartyプラグインのテストのファイル名とクラス名を変更したので、テストを実行したところ、手元の環境ではエラーになり、別サーバではエラーにならないということがあった。

Ethna本体のテストは、bin/ethna_run_test.php の中で、opendir() -> readdir() でテストクラスを取得してきてテストを実行するという形式だが、これの取得順が違うようだ。
もちろん、順番に依存するテストケースというのは間違っているので修正するべきだが、環境によってはそれで動いてしまっているので気がつきにくい場面があるのかもしれない。

http://maru.cc/~maru/ethna/test_result/test_server1.txt
http://maru.cc/~maru/ethna/test_result/test_server2.txt
※そのうち消します

TODO:あとで、原因を追ってみる。

追記
原因判明しました。
Ethna_ActionForm_Testがこけていたのを直した - maru.cc@はてな

JSでIE5.5とか切る方法は？

ちょっと案件で、JSでフォームの動作を制御している場合に、IE5.5で正常に動かないということがありました。
元々、JSを切っていても動くようにしていたので、古いIEでは、そちらに振り分けようとなったのだが、最近のJS動作振り分けはどんな方法がいいのだろうか？

ということでいくつか調べた方法。

こちらは、Mozilla Japanのサイトに載っていた「究極の JavaScript クライアント判別, Version 3.03」というもの。
http://www.mozilla-japan.org/docs/web-developer/sniffer/browser_type_oo.html

もしくは、こちらの掲示板で見つけた JScriptでの条件コンパイルを使用した方法。
http://www.tagindex.com/kakolog/q4bbs/1201/1523.html
（#3の方の発言がまとまっていてわかりやすいです）

MSの情報
http://msdn.microsoft.com/en-us/library/7kx09ct1(VS.71).aspx

最終的には、べつで使用していたライブラリを使ったので、navigator.userAgent から正規表現で当てる方法になりましたが。
どの方式がベターなのでしょうか？