タイトル/名前 | 更新者 | 更新日 |
---|---|---|
PHP/log4phpメモ | msakamoto-sf | 2008-12-21 23:47:14 |
PHP/MySQL_BLOBに画像を保存するサンプル | msakamoto-sf | 2008-12-21 23:41:00 |
添付ファイル/PHP/blob1.zip | msakamoto-sf | 2008-12-21 23:35:07 |
添付ファイル/PHP/qf_sample20050704.zip | msakamoto-sf | 2008-12-21 23:34:01 |
添付ファイル/PHP/QFSmartyRendererLight.class.php | msakamoto-sf | 2008-12-21 23:33:46 |
PHP/HTML_QuickFormメモ/20050814/hierselect使用時の注意点 | msakamoto-sf | 2008-12-21 22:52:06 |
PHP/HTML_QuickFormメモ/20050717/Smartyレンダラ改良版 | msakamoto-sf | 2008-12-21 22:49:38 |
PHP/HTML_QuickFormメモ/20050710/dateエレメントの日付フォーマット | msakamoto-sf | 2008-12-21 22:42:51 |
PHP/HTML_QuickFormメモ/20050704/sample | msakamoto-sf | 2008-12-21 22:40:18 |
PHP/HTML_QuickFormメモ/20050615/SmartyRendererが遅い | msakamoto-sf | 2008-12-21 22:32:44 |
2005年12月当時、log4php-0.9を使っていた時のメモです。log4phpも暫くバージョンがアップしていないと思っていたら、
http://incubator.apache.org/log4php/index.html
として復活したようですが・・・。でもPHP5対応を謳っている(らしい)バージョン2.0のソースはまだ出ていなかったり。
SF.jpの方で「PHPCommons」プロジェクトの方で対応していたりと、何だかドタバタしてます。
http://sourceforge.jp/projects/phpcommons/
個人的にはPEAR_Logでいいやもう、という感じで、YakiBikiでもPEAR_Logにしています。
但し2005年12月当時は自分の中ではlog4phpだったんです。恐らくお仕事の方でlog4jを使っていたので、設定の仕方とかがそのまま使い回せたからでしょう。あと一応Apache内だったから?かも・・・。
log4phpのバージョン0.9のお話です。
log4phpは、基本は設定ファイルを用意してそれを"LOG4PHP_CONFIGURATION"で指定して使います。そのため、「動的に設定を取得したい(例えばDBからlog4phpの設定を動的に作りたい)場合はどうするの?」となります。
対処の一例が今回ので、 LOG4PHP_CONFIGURATOR_CLASS を利用して、ファイルを使わない自作の設定クラスを指定します。
話を早くするために、とりあえずサンプルです。$logger_propertiesという連想配列を設定として用いるSampleConfiguratorというクラスを作りました。
[SampleConfigurator.php] // クラス名.phpという形式にする必要があります。 <?php // LOG4PHP_DIRの定義は、タイミング上ここで平気です。 require_once(LOG4PHP_DIR.'/LoggerPropertyConfigurator.php'); class SampleConfigurator extends LoggerPropertyConfigurator { function SampleConfigurator() { $this->loggerFactory = new LoggerDefaultCategoryFactory(); } // LoggerManagerの初期化関数からこのメソッドがstaticに呼ばれます。 // ので、オーバーライドしておきます。 function configure($url = '') { // SampleConfiguratorをnewするように修正します。 $configurator = new SampleConfigurator(); // $configurator = new LoggerPropertyConfigurator(); ←元 $repository =& LoggerManager::getLoggerRepository(); return $configurator->doConfigure($url, $repository); } function doConfigure($url, &$repository) { // 外部で定義された連想配列(parse_ini_file()したのと同じ形)を使用 global $logger_properties; $properties = $logger_properties; return $this->doConfigureProperties($properties, $repository); } } ?>
とどのつまり、 parse_ini_file()で読み込んでいたところを、どうにかしてそれと同じ形の連想配列をセットできれば良い わけです。
で、これを利用する側は・・・
$base_dir = realpath(dirname(__FILE__)); define('LOG4PHP_CONFIGURATOR_CLASS', $base_dir.'/SampleConfigurator'); $logger_properties = array( "log4php.logger.test01" => 'DEBUG, A1', "log4php.appender.A1" => 'LoggerAppenderEcho', "log4php.appender.A1.layout" => 'LoggerPatternLayout', "log4php.appender.A1.layout.ConversionPattern" => '"%d{ISO8601} [%p] %m%n"', ); require_once("(...)/log4php/LoggerManager.php"); $logger =& LoggerManager::getLogger("test01"); ...
こんな感じになります。
LOG4PHP_CONFIGURATOR_CLASSのフォーマットに注意してください!!ファイル名末尾の".php"は不要です!!
というのは、LOG4PHP_CONFIGURATOR_CLASSのbase_name()をクラス名としているため、".php"がついてしまうとまずいわけです。これがひいては、クラス名とファイル名をJava風に一致させる必要につながります。
さらに言うと、この制限により
define('LOG4PHP_CONFIGURATOR_CLASS', realpath(dirname(__FILE__).'/SampleConfigurator'));
みたく出来ないわけです。クラス名になってしまっているため、realpath()が見つからなくなってしまうからです。
以上のような点に注意して頂ければ、設定ファイルに依らない、柔軟なlog4phpの設定を行うことが可能になります。
2005年6月前後、MySQLのBLOB型のカラムにアップロードされた画像データを保存するサンプルです。
ADODB, Smarty, HTML_QuickFormを使っています。当時の自分はこのライブラリの組み合わせを使っていました。
それぞれのライブラリのテクニックを色々調べつつ作ったのでかなり拙い出来ですが、これも自分の一部ですし、捨てるにはちょっと惜しいかなと思ったので上げておきます。
hierselect(階層化selectメニュー)はQuickFormの中でも、dateと並んでおもしろい使い勝手を実現しているエレメントです。
が。
使うときにちょっとしたミスをしたため 「動かねえ~~~。JavaScriptでエラーでてるっぽい~~。_hs_swapOptionsとかいう関数が何で出力されないんじゃあ~~~」 という具合に見事嵌ってしまいました。
えーっとですね。まず、hierselectはJavaScriptで高度な階層化メニュー構造を実装しています(*1)。んで、hierselectってHTMLコードを生成するときに、使用するJavaScript関数を何回も出力してしまわないよう、内部で defineによるフラグを管理 してます。(何回も出力すると当然JavaScriptのエラーになってしまうので。)
んで、今回嵌ったのは次のような状況です。
以上のような状況だと、最初のQuickFormオブジェクトで、hierselectのJavaScriptがSmartyにassign()されます。二つめのQuickFormオブジェクトがassign()、すなわちtoArray()(←toHtml())される場合は、既にdefineフラグが立っていますので、hierselectのJavaScriptはHTMLコードに含まれません。
ところが、最初のQuickFormオブジェクトがassign()されたHTMLを、Smartyのテンプレート側で無視して出力していません。
→その結果、最初のQuickFormオブジェクトがtoHtml()されたHTMLコードに含まれているJavaScriptが出力されないため、二つめのQuickFormに含まれるhierselectのJavaScriptは動きません。
えーっと、そんな具合で。とにかく、「最初の一度だけ出力されるJavaScriptを出力していなかった」為に、続くhierselectのHTMLコードが軒並みHTMLエラーになってしまった・・・という話。
というわけで、複数作ったQuickFormオブジェクトを、それぞれで出力したりしなかったりすると、結構嵌るかもしれないです。特にテンプレート使ってて、toHtml()はしてるが肝心のテンプレートの方でそれを出力していないと・・・こうした「一回目のtoHtml()」が出力されないんで、結構嵌るかも知れません。
2005/06/15の解法(メソッド上書き)ではカスタマイズ性に乏しく、また、全要素に関して呼ばれてしまうという問題がありました。
PHP/HTML_QuickFormメモ/20050615/SmartyRendererが遅い
このため、_elementToArray()を上書きして全て呼ばれてしまう部分を切り分け、エラーかrequired時のみカスタマイズに流れるようにしました。また、エラーとrequiredの組み合わせの実現方法としてはビット定義の組み合わせを用い、一カ所でまとめて行えるようにしました。
添付ファイル/PHP/QFSmartyRendererLight.class.php
2005年6-7月当時は、これによりクラスに手を加えることなく比較的楽にSmartyレンダラを使っていました。
PEAR Bug Report: http://pear.php.net/bugs/bug.php?id=4781
ver 3.2.5 で修正されました。
dateエレメントを利用する場合、setDefaults()を呼ばないと、コンストラクタで'format'で渡した日付フォーマットが正しくHTML化されません。
$form->addElement('date', 'date1', 'date1_capt', array('format' => '年月日:Y 年 m 月 d 日', ...
このように、いわゆるPrefix/Suffixのあるformatの場合、setDefaults()を呼んでおかないとPrefix/SuffixがHTML化したとき表示されない問題があります。つまり、 "Y 年 m 月 d" までが解析されて表示され、"年月日:"および" 日"部分は表示されません。
これはdateエレメントのtoHtml()関数が呼ばれるタイミングに関係しており、レンダラクラスとは無関係に発生します。(QuickFormをダウンロードして付いてくるサンプルでも簡単に再現できる現象です。)
これを解決するには、date.php のtoHtml()関数を以下の用に修正します。
function toHtml() { include_once('HTML/QuickForm/Renderer/Default.php'); $renderer =& new HTML_QuickForm_Renderer_Default(); $renderer->setElementTemplate($this->_wrap[0] . '{element}' . $this->_wrap[1]); parent::accept($renderer); return $renderer->toHtml(); }
function toHtml() { include_once('HTML/QuickForm/Renderer/Default.php'); $renderer =& new HTML_QuickForm_Renderer_Default(); $renderer->setElementTemplate('{element}'); // ^^^^^^^^^^^ →$this->_wrapを削除 parent::accept($renderer); return $this->_wrap[0].$renderer->toHtml().$this->_wrap[1]; // ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ →こちらに$this->_wrapを追加 }
formatの解析は、date.phpの_createElements()メソッド内で行われます。$this->wrap[0], [1]にそれぞれPrefix/Suffixが_createElements()内でセットされます。
問題は_createElements()の呼ばれるタイミングで、accept()(すなわちtoHtml)の呼ばれる前に、dateエレメントに対して何らかの値の操作を行うと、自動的に呼ばれます。たとえばsetDefaults()がそのケースです。逆に言えば値の操作なしでいきなりaccept()に入ると、その時点で初めてformatの解析が行われるわけです。
修正前のdate.phpではこの結果、いきなりaccept()が呼ばれると$this->wrap[]が空のままsetElementTemplateに流れ込み、結果としてPrefix/Suffixが取り込まれずにHTML化されるようです。
少しvar_dumpなどで解析した結果、setElementTemplate内では何らかのタイミングで_createElements()が呼ばれているようです。いきなりaccept()を呼んだ場合でも、setElementTemplateの前では$this->_wrapが空でしたが、呼んだ後ならちゃんとPrefix/Suffixが入っていました。
よって解決策としてはsetElementTemplateの「後に」$this->_wrapを利用することが考えられます。そこで、$this->_wrapをtoHtml()がリターンする直前に連結して使用するよう変更したわけです。これでとりあえずQuickForm添付のサンプルとか、自分で弄ってるSmartyRendererとかでは正常に表示されるようになりました・・・。
QuickFormをダウンロードしてついてくるサンプルが、80桁改行をしていないため激しく読みづらい。
しかも「全部入り」的になっていて初めての人にはコードが多すぎて分かりづらいのでは?
ということで自分でSmartyレンダラを使用したサンプルをでっち上げました。
添付ファイル/PHP/qf_sample20050704.zip
実行するにはSmartyが必要です。ファイルを展開して、中のPHPファイルのrequire部分を適宜Smartyの実行環境のパスに書き換えて下さい。あとSmartyのコンパイルディレクトリはとりあえずCurrentDirectoryにしてありますので、Linux/UNIX系はご注意下さい。
なおこのサンプルには PHP/HTML_QuickFormメモ/20050615/SmartyRendererが遅い で作った、独自のSmartyレンダラを使うようになってます。
2005年6月前後のHTML_QuickFormについての話となります。アップデートできてなくて御免なさい。
HTML_QuickFormでレンダリングする時、Smartyレンダラを使うとやたらと処理が重くなる現象が2005年6月当時発生していました。1500msほどがSmartyレンダラの処理で費やされていました。
xdebugで追い掛けたところ、HTML_QuickFormのデフォルトのSmartyレンダラは
で指定されたSmartyテンプレートを 要素毎に
これら二つのメソッド内部で、 ローカルにSmartyコンパイルしている というとんでもない事実がありました。だから遅かった訳です。
逆を言えば、そもそもrequiredやerrorの時にSmartyテンプレートを 使わなければ 、毎度毎度Smartyコンパイルする必要もないわけです。
よって、以下のような派生クラスを用意してこれをレンダラとして使うことにしました。
class FastQuickFormRenderer extends HTML_QuickForm_Renderer_ArraySmarty { // _required, _error が定義されていないと、各rendererが呼ばれない。 var $_required = " "; // ダミーで良いので定義しておく。 var $_error = " "; function HTML_QuickForm_Renderer_ArraySmartyLight (&$tpl, $staticLabels = false) { $this->HTML_QuickForm_Renderer_ArraySmarty($tpl, $staticLabels); } function _renderRequired(&$label, &$html, &$required, &$error) { if(!empty($error)) { $label = sprintf('<span style="color: red;">%s</span>', $label); } else { if(!empty($required)) { $label .= '<font color="red">*</font>'; } } } function _renderError(&$label, &$html, &$error) { if(!empty($error)) { $html .= '<br /><span class="qferror_html">'.$error.'</span>'; } } }
Smartyコンパイラを起動する関数を、単なる文字列処理に上書きしてしまうわけです。んで、この上書きしたレンダラクラスを使用すればオッケーな訳です。
Smartyを使うほど凝ったレンダリングが必要なわけではなくて、単にエラーとかその辺りをちょっとアプリ側でカスタマイズできれば良かったので、この程度でOKでした。
・・・何で2005年当時はSmartyレンダラ使おうと思ったのかな?単にアプリ側でSmartyを使ってたからかな?思い出せない・・・。