2006-06-02 (金)
■ Ethna のテンプレートエンジンに Simplate を使う
Ethna のテンプレートエンジンに、 Simplate を使えないか試してみる。
Ethna.php の以下の行をコメントアウト。
include_once('Smarty/Smarty.class.php');
class/Ethna_Controller.php の $smarty =& new Smarty(); の部分を 以下のように変更。
$smarty =& new simplate();
$smarty->left_delimiter = '{';
$smarty->right_delimiter = '}';
これだけだと、 Smarty で使えて Simplate で使えない関数の部分でエラーが出るので、 さらに以下の箇所を修正。
- class/Ethna_Controller.php の中で、register_modifier(), register_function(), register_block() を呼んでいる箇所を全てコメントアウト
- class/Ethna_ViewClass.php の中で、assign_by_ref() を呼んでいる箇所を全て assign() に変更
これで、デフォルトの index.php は表示できた。
次に、Ethna のチュートリアルのサンプルを、 テンプレートを修正して動くようにしてみる。
まず、以下の箇所がひっかかる。
{foreach from=$errors item=error}
<li>{$error}</li>
{/foreach}
Simplate では foreach 文は使えないようなので、 代わりに section 文を使って以下のように書く。
{section name=i loop=$errors}
<li>{$errors[i]}</li>
{/section}
次に、以下の箇所でひっかかる。
{message name="password"}
こういう Smarty 関数の呼び出しは Simplate ではできないので、 とりあえずこの部分は削除する。
以上の修正で、チュートリアルのサンプルも動かすことができた。
■ Ethna のテンプレートエンジンに Simplate を使う (2)
{message name="password"} と Smarty 関数を使っているところを、 PHP の関数の直接呼び出しにしたら動くんじゃないかと思い、 以下のように書き換えてみた、
{smarty_function_message('password')}
ところが、以下のようなエラーが出る。
Sample[747](WARNING): global.smarty_function_message(/tmp/login.tpl:17): [PHP] E_WARNING: Missing argument 2 for smarty_function_message(), called in /home/revulo/Ethna/sample/tmp/login.tpl on line 17 and defined in /usr/share/php/Ethna/class/Ethna_SmartyPlugin.php on line 417 Sample[747](WARNING): global.extract(class/Ethna_SmartyPlugin.php:421): [PHP] E_WARNING: extract() [function.extract]: First argument should be an array in /usr/share/php/Ethna/class/Ethna_SmartyPlugin.php on line 421
なに？ 配列をよこせだと？ おまけにもう１つ引数が必要？？ どういう関数になっているのか見てみる。
function smarty_function_message($params, &$smarty)
{
$c =& Ethna_Controller::getInstance();
extract($params);
$action_error =& $c->getActionError();
print htmlspecialchars($action_error->getMessage($name));
}
ということは、 array('name' => 'password') みたいな連想配列を引数に取るということか？ あと、２番目の引数が必須になっているが、その割に使われていない。 これは、内部で smarty_function_message() を呼び出すような 別の関数を作らないとダメかな。
2006-06-03 (土)
■ Ethna のテンプレートエンジンに Simplate を使う (3)
Ethna_Flexy.php を見てみると、 HTML_Template_Flexy_SmartyAPI クラスを拡張して Smarty クラス（もどき）を定義していた。 いいな、このやり方。自分もやってみよう。
Ethna_Simplate.php の雛型を作ってみた。 最初 simplate() メソッドを呼ぶように書いたらエラーになったので、 parent::__construct(); に書き直した。 そのため、PHP5 以上必須。
<?php
define('SMARTY_DIR', '');
class Smarty extends simplate
{
function Smarty()
{
parent::__construct();
$this->left_delimiter = '{';
$this->right_delimiter = '}';
}
function assign_by_ref($key, $value)
{
$this->assign($key, $value);
}
function register_modifier()
{
}
function register_function()
{
}
function register_block()
{
}
}
?>
これを、Ethna の class ディレクトリにインストール。
Ethna.php の以下の行をコメントアウト。
include_once('Smarty/Smarty.class.php');
Ethna.php に以下の行を追加。
include_once(ETHNA_BASE . '/class/Ethna_Simplate.php');
これだけの作業で、Ethna 本体をいじらなくても Simplate が使える。
2006-06-04 (日)
■ Ethna のテンプレートエンジンに Simplate を使う (4)
Ethna の Ethna_SmartyPlugin.php を見てみたが、 smarty_function_is_error() と smarty_function_message() 相当の機能は使えた方が良さそうだ。
smarty_function_is_error() については、 is_error() というメソッドが Ethna_Util.php で定義されていたので、 それを使えばＯＫ。
smarty_function_message() の方はどうすればいいか？
function smarty_function_message($params, &$smarty)
{
$c =& Ethna_Controller::getInstance();
extract($params);
$action_error =& $c->getActionError();
print htmlspecialchars($action_error->getMessage($name));
}
これをまねて、以下のようなメソッドを、 昨日の Ethna_Simplate.php に追加する。
function error_message($name)
{
$c =& Ethna_Controller::getInstance();
$action_error =& $c->getActionError();
print htmlspecialchars($action_error->getMessage($name));
}
使う時は、テンプレートの中で、 {error_message('password')} のように書けばよい。
■ Ethna のテンプレートエンジンに Simplate を使う (5)
これまでの実験結果を Wiki に、 Ethna のテンプレートエンジンに Simplate を使う としてまとめておいた。
いくらか試行錯誤したが、結果的には、 Ethna で Simplate を使うのは非常に簡単だと言えると思う。
2006-06-07 (水)
■ セッションの使い方
Ethna でのセッションの使い方について、 ドキュメントにあまり書かれていない点をメモ。
- $this->session->start(); してやらないとセッションは使えない。
- テンプレート中では、セッションの値は {$session.***} で参照できる。
- ActionClass の authenticate() というメソッドが prepare() の前に実行される。セッションとか認証がらみの処理はここで行うと分かりやすい。
あと Ethna_Session.php を見ると、匿名セッションというのがあった。 何だろう、これは？ 使い方としては、 $this->session->start(0, true); のようにセッションを開始し、 $this->session->isAnonymous(); や $this->session->isStart(); で判別するようだが、 使い道がいまいち分からない。
■ Ethna 2.1.2 がリリース
2.1.0 にアップデートしたばかりなのに… orz
というのも、 Simplate の組み込み とか、 Ethna のシステムの一部を書き換えて実験しながら使っているので、 バージョンアップの作業が少し面倒なのです。
2006-06-08 (木)
■ 遷移先の指定とリダイレクト
return '******'; での遷移と、 header('location: ******'); でのリダイレクトの違いについて、 つまづいたのでメモ。
例えば、こんな掲示板を作ることを考えてみる。
- ゲストは、記事の閲覧のみ
- 登録ユーザーは、投稿もできる
ここで、投稿用のページにゲストが直接飛んできた場合に、 どう処理すればよいか？ 注意しなければならないのは、 アクションクラスの中で指定する遷移先というのは、あくまでも表示画面の指定だということ。 つまり、
- アクションクラスの prepare()
- アクションクラスの perform()
- テンプレートの表示
という流れなので、 prepare() の中で遷移先を指定して飛ばしてしまうと、 データベースの読み込みとか、 通常 perform() 内で行われる処理が何もされずに、 画面表示のフェーズにいってしまう。 よって、この例の場合、 ログイン画面に飛ばしたりするのならば問題は起こらない。 しかし、記事閲覧ページに飛ばしたりすると、 記事が何も表示されない、ということになる。
さて、こういう場合にどうすればいいのか？ いくつか解決法を考えたが、結局のところ、 return '******'; のような遷移先の指定でなく、 header('location: ?action_****=true'); のようにして、 リダイレクトさせてしまうという案に落ち着いた。 そうすれば、そのアクションの perform() も実行される。
ただし、return '******'; の遷移先の指定で済む場合もあるので、 両方を使い分けるのがいいと思う。
2006-06-11 (日)
■ ActionForm の使い方メモ
ActionForm に値を格納するメソッドは以下の３種類。
- setApp()
- setAppNE()
- set()
それぞれテンプレート中では以下のように使われる。
| メソッド | テンプレートでの値の取得方法 | 値のエスケープ |
|---|---|---|
| setApp() | {$app.〜} | される |
| setAppNE() | {$app_ne.〜} | されない |
| set() | {$form.〜} | される |
さて、これらをどう使い分ければよいのか？ 一言で言うと、単なる表示の場合は setApp()、 フォームの値の場合は set() という感じだと思うが、 いくつかの例を箇条書きにしてみる。
set() を使うケース
- フォームに初期値を設定する場合
フォーム画面でデータの編集をするような場合、 Validation に引っかかり再びその画面に戻ってくる場合を考えると、 テンプレートでは {$form.〜} として値を参照しなければならない。 よって、初期値を ActionForm に渡す際にも、 それに合わせて set() を使う。
setApp() を使うケース
- セレクトボックス用の配列を渡す場合
例えば、何月なのかを選んでもらうために、
$months = range(1, 12);
$this->af->setApp('months', $months);
のような配列をセットする場合。 フォームだから set() を使うのかと一瞬考えたりしたが、 値を表示するだけで書き換えるわけではないので、 setApp() を使うのが適切。
setAppNE() を使うケース
- HTML タグとして解釈したい文字列を含んでいる場合
例えば、Topic Path を表示するための HTML を PHP スクリプト中で組み立てておいて、 それをテンプレートに渡す場合とか。
2006-06-13 (火)
■ perform() と preforward() の使い分け
先日 にも例として出したコードだが、 テンプレート中でセレクトボックスの表示に使うこのような配列は、 どこで定義するのが妥当なのか？
$months = range(1, 12);
$this->af->setApp('months', $months);
最初、perform() の中にこのコードを書いていたが、 もしかするとこれは preforward() とやらに書くべきなのでは？ そう思いながら処理の続きを書いてみて分かったが、 やはりこれは preforward() に書かないといけない。
以前書いた処理の順番 をもう少し詳しく書くと、
- アクションクラスの authenticate()
- アクションクラスの prepare()
- アクションクラスの perform()
- ビュークラスの preforward()
- テンプレートの表示
という順番で処理されていく。
return '******'; で遷移すると、 preforward() のところに飛んでいき、 perform() の処理は行われない。 だから、エラーで再入力を促す場合を考えると、 上のような処理は preforward() で行わないといけない。
逆に、編集画面の初期値を設定するような場合には、 もし preforward() でその処理を行ってしまうと、 入力のエラーで同じビューに戻ってきた場合に、 ユーザーがせっかく変更した値が上書きされてしまう。 だから、perform() 内で行うのが適切。
うん、ようやく分かってきた気がする。
2006-06-14 (水)
■ 現在実行中のアクション名を得る
現在実行中のアクション名を知りたい時、どうすれば良いか？ Ethna のソースコードの中を探してみると、 Ethna_Controller クラスに、 getCurrentActionName() というメソッドがあるのを見つけた。 アクションクラスやビュークラスからなら、 $this->backend->ctl->getCurrentActionName() のようにたどれば値を得ることができる。
さらに、テンプレート中でもアクション名を参照できるようにしたいので、 ???_Controller クラスの _setDefaultTemplateEngine() メソッドに、 以下のコードを追加してみた。
$this->action_form->set('action', $this->action_name);
これで、テンプレート中から {$form.action} で、 現在のアクション名が得られるようになる。
2006-06-17 (土)
■ Ethna で PDO を使うサンプル (2)
以前書いたサンプルだが、 AppManager クラスを継承させた方が楽 （というか、そうすべき）だと分かったので、 こんな風に書き直していた。
<?php
class Sample_UserManager extends Ethna_AppManager
{
function auth($mailaddress, $password)
{
$sql = 'SELECT password FROM user WHERE email=?';
$dbh =& $this->backend->getDB();
$stmt = $dbh->prepare($sql);
$stmt->bindparam(1, $mailaddress);
$stmt->execute();
$md5pass = $stmt->fetchcolumn();
$stmt->closeCursor();
if ($md5pass != md5($password)) {
return Ethna::raiseNotice('パスワードが違います', E_SAMPLE_AUTH);
}
return 0;
}
}
?>
つまり、データベース接続用のオブジェクトを、
$dbh =& $this->backend->getDB();
とすることで得ていた。
ところで、Ethna_AppManager クラスには $db というプロパティがある。 この $db は $this->backend->getDB(); を実行するまで 設定されないと思っていたのだが、 よく調べると、コンストラクタの中で間接的に getDB() を呼んでいた。 ということで、getDB() を自分でいちいち呼びだす必要は無い。 コードも以下のようにすっきりと書ける。
<?php
class Sample_UserManager extends Ethna_AppManager
{
function auth($mailaddress, $password)
{
$sql = 'SELECT password FROM user WHERE email=?';
$stmt = $this->db->prepare($sql);
$stmt->bindparam(1, $mailaddress);
$stmt->execute();
$md5pass = $stmt->fetchcolumn();
$stmt->closeCursor();
if ($md5pass != md5($password)) {
return Ethna::raiseNotice('パスワードが違います', E_SAMPLE_AUTH);
}
return 0;
}
}
?>
ただし、試してはいないが、 リードオンリーで接続したいとかいう場合は、 改めて getDB() を使ってデータベース接続するのだと思う。
2006-06-18 (日)
■ 内部文字エンコーディング
Ethna で作成したアプリをデバッグしていて気が付いた。 'filter' => FILTER_HW, と設定したフォームに、 全角文字の入力を与えても半角に変換されない。 なんでかな？ と思い、 echo mb_internal_encoding(); で文字コードを確認してみたところ、
ISO-8859-1
と表示された。そりゃあ、変換されないわな。 まぁ、他の人がビルドしたパッケージを そのまま使っている自分が悪いのだが。 とりあえず、php.ini に以下のように設定したら解決した。
default_charset = EUC-JP mbstring.language = Japanese mbstring.internal_encoding = EUC-JP mbstring.substitute_character = none
しかし、こういう解決法でいいのだろうか？ より汎用性を高めるためには、 こういう設定って、PHP のスクリプト中、 もっと言えば Ethna の中でやるべきな気もするんだが。
■ PukiWiki 1.4.7 と siteDev2 がリリース
PukiWiki 1.4.7 が告知はまだだがリリースされている。 高速化だとか、UTF-8 バージョンだとか、 面白そうなのでそのうちアップデートしておこう。
あと、それと前後するように、 siteDev2 がリリースされている。 個人用に特化した PukiWiki といったところだろうか？ ベースとなる PukiWiki のバージョンが古かったので使用は見合わせていたが、 今回、PukiWiki 1.4.6 ベースとなり、 しかも Smarty 化したと書かれていたので試してみた。
感想。
PukiWiki に比べて使いやすいかどうかは疑問。 ソースコードのハイライトプラグインだとか、 個々の機能は結構魅力的なのだが、 設定ファイルに生パスワードを書かせるとか、 ちょっと？？？な部分がある。
あと、Smarty 化というのも期待外れ。 キャッシュ制御などをしてくれるのかと思ったが、 単純に pukiwiki.skin.php から HTML の部分を テンプレートとして抽出しただけという感じ。 確かにページのデザインはしやすくなるが、 なんというか、今一歩、という感じがする。
■ キャッシュ利用による高速化
siteDev の Smarty 化にちょっとがっかりしたので、 PukiWiki でキャッシュを利用するための予備実験として、 PukiWiki のプチ改造をしてみた。 要するに、毎回 wiki/*.txt から html に変換するのでなく、 変換した html を保存しておこうという考え。
詳細は こちら に載せておく。
試しに整形ルールのページを表示してみたら、 以下のような結果になった。
| 改造前 | HTML convert time: 0.320 sec. |
| 改造後 | HTML convert time: 0.024 sec. |
ここまでやった後、 「PukiWiki」「高速化」で検索してみたら、 以下のようなページが出てきた。
やっぱり、同じようなことを考えてる人がいた。 ここで手を引くべきか、それとももう少し突っ込んでやってみるべきか。 さてどうしよう。
2006-06-21 (水)
■ PDOStatement::prepare() メソッドの連続コール
PDO_MYSQL 限定の話かもしれないが、 複数の prepared statements を連続で登録することはできないようだ。 どういうことかというと、
$stmt1 = $dbh->prepare($sql1); $stmt1->execute(); $stmt2 = $dbh->prepare($sql2); $stmt2->execute();
みたいなのはＯＫだが、
$stmt1 = $dbh->prepare($sql1); $stmt2 = $dbh->prepare($sql2); $stmt1->execute(); $stmt2->execute();
のような順番にするとおかしな動作になる。 $sql1 の SQL 文は実行されず、 場合によっては、$sql2 の SQL 文が２回実行されたりする。
2006-06-22 (木)
■ Prepared statements と WHERE IN
どうも、この両者は相性が悪いようだ。
こんな感じのコードを組んでみた。
$sql = '〜 WHERE id IN (?)';
$id = array(1, 2, 5);
$list = implode(',', $id);
$stmt = $dbh->prepare($sql);
$stmt->bindparam(1, $list);
$stmt->execute();
イメージとしては、
〜 WHERE id IN ('1','2','5')
のような SQL 文に翻訳されることを何となく期待していたのだが、 実際に実行された SQL 文は、
〜 WHERE id IN ('1,2,5')
であった。 考えてみれば当たり前だが… orz
配列のサイズと同じ回数だけループを回して、 その中で SQL 文への？の追加と bindparam を行えばいいのだろうが、 コードの視認性が下がるし、 配列のサイズによって SQL 文が変わってしまうので使い勝手が悪い。
ということで、WHERE IN を使う場合は、 SQL インジェクションに気をつけながら、 プレースホルダーを使わない SQL 文を組み立てた方が良さそうだ。
2006-06-23 (金)
■ 未選択のチェックボックスが返す値
チェックボックスのフォームから値を得る場合、 VAR_TYPE_BOOLEAN と指定することも関連して、 以下のような動作を期待していた。
- チェックが入っていれば１
- チェックされていなければ０
ところが、これがなかなかうまくいかない。 IE6 で実験してみたところ、チェックボックスというのは、
- チェックされていなければ何も返さない
- チェックが入っていれば value の値を返す
- value が設定されていなければ on を返す
という動作をするようだ。 この何も返さないというのが曲者で、Ethna の $form の指定で、
'required' => true,
にしていると、チェックがされていない場合に、 「〜を選択して下さい」と再入力を促されてしまう。
じゃあ、filter の機能を使って強引に０か１にしたらどうかと、 こんなフィルタを適用してみた。
function _filter_boolean($value)
{
return ($value) ? 1 : 0;
}
しかし結果は変わらず。 Ethna のソースを見て確認してみたところ、 確かに順序としては、 フィルタの適用後に required の条件判定が行われるのだが、 そもそも何の値も渡って来ていないのだから、 フィルタも適用されず空のままということのようだ。
ならば、VAR_TYPE_BOOLEAN の値をサーチして、 強制的に０か１に変換するメソッドを用意したらどうだろう？ こんなメソッドを ActionForm クラスに追加してみた。
function filterBooleanCheckbox()
{
foreach ($this->form as $name => $def) {
if ($def['type'] == VAR_TYPE_BOOLEAN &&
$def['form_type'] == FORM_TYPE_CHECKBOX) {
$this->form_vars[$name] = ($this->form_vars[$name]) ? 1 : 0;
}
}
}
このメソッドを $this->af->validate() する前に呼び出せば、 必ず０か１の値が入っている状態になる。
ところで、この VAR_TYPE_BOOLEAN かつ FORM_TYPE_CHECKBOX という条件判定は、 冗長のように思えるかもしれないが、片方の条件だけだと、 以下のような場合にも変換が行われてしまい、不具合が生じる。
- 'form_type' => FORM_TYPE_RADIO, 'type' => VAR_TYPE_BOOLEAN のケース
例えば、性別を選択する２択のラジオボタンを用意して、 男性なら０、女性なら１を返すようにする場合。 この場合、未選択と０とは別物なので、 未選択→０ の変換を勝手にしてはまずい。
- 'form_type' => FORM_TYPE_CHECKBOX, 'type' => array(VAR_TYPE_INT) のケース
例えば、好きなものを３つまで選んでもらうためのチェックボックスの場合、 フォームの定義はこのようになる。
2006-06-24 (土)
■ Wiki の Ethna ページの引越し
Ethna のネタが増えてきたので、 Wiki の PHP/Ethna の下にあるページを 今のうちに引越しさせることにした。 ページの URL の新旧対応表がこれ。
| PHP.html | 単なる目次ページだったので削除 |
| PHP/Ethna.html | Ethna.html |
| PHP/Ethna/Simplate.html | Ethna/Hack/Simplate.html |
| PHP/Ethna/Install.html | Ethna/Install.html |
新ページにリダイレクトするようにしたいのだが、 このように一貫したルールが全然無い。 面倒なので、全部 Ethna.html にリダイレクトすることにして、 .htaccess ファイルに以下の設定を追加した。
RewriteRule ^PHP(.+)$ Ethna.html [R=301,L]
見よう見真似で設定してみたが、 これでうまくリダイレクトできているようだ。
2006-06-26 (月)
■ 1.4.7 にバージョンアップ
昨日はいろいろ作業して、疲れてそのまま寝てしまった。 作業した内容は、
- PukiWiki を 1.4.7 にバージョンアップ
- RewriteMap プラグインの PukiWiki 1.4.7 対応
- Wiki の Ethna のページを拡充
こんなところか。
PukiWiki の改造をあちこちしていたため、 バージョンアップ作業が大変だった。 まぁそれでも、 修正内容をパッチの形にしておいたり、 文書にまとめておいたりはしたので、 それに従って作業するだけで済んだのは助かったが。
それと、バージョンアップ作業の途中で、 RewriteMap プラグイン 用のパッチがうまくあたらない箇所があったので、 PukiWiki 1.4.7 用のパッチを新たに作成した。 RewriteMap 1.0a としてアップしておく。
■ Wiki の Ethna ページの引越し (2)
先日、Ethna 関連ページの構成を変更して、 新ページへのリダイレクトの設定を行った が、不具合が生じていたことが分かった。
Wiki 以外の html ファイルにアクセスすると、 なぜかトップページに飛ばされてしまい、 メール送信フォームとか、アクセスログとか、 そういったページが見られなくなっていた。 .htaccess ファイルに、
RewriteCond %{REQUEST_FILENAME} !-f
と設定しているのに、それが無効になってしまった感じだ。
どうにも解決法が分からないので、 リダイレクトの設定は解除することにした。 Ethna の旧ページにアクセスしてくると、 トップページに飛ばされてしまうことになるが、 もう面倒なのでこれでよしとする。
2006-06-27 (火)
■ template ディレクトリが階層構造をしている場合
Ethna では、当たり前のように、 template ディレクトリの下に更にディレクトリを作ったりする。 ところがどうも、Simplate はそういう状況に対応していないようだ。
login_do というビューに対するテンプレートを、 login/do.tpl という名前で置いて実行してみたところ、 以下のようなエラーが出た。
fail to open: /home/revulo/Ethna/sample/tmp/login/do.tpl
tmp ディレクトリの下を見てみると、 確かに login というディレクトリや do.tpl というファイルが存在しない。 テンプレートエンジンを Smarty に切り替えると問題なく表示されるので、 どうも Simplate に限った現象のようだ。
仕方ないので、app/Sample_Controller.php の $forward に、 以下のような設定を追加する。
'login_do' => array(
'forward_path' => 'login_do.tpl',
),
そして、login/do.tpl を login_do.tpl にリネーム＆コピーする。 これでとりあえず動くようになった。
2006-06-28 (水)
■ template ディレクトリが階層構造をしている場合 (2)
昨日の問題について。 Ethna の公式ページを見たら、もっと良い解決法が書かれていた。 「テンプレート定義省略時の命名規則を変更する」 に従い、Controller クラスのメソッドを以下のようにオーバーライドする。
function getDefaultForwardPath($forward_name)
{
return $forward_name . '.' . $this->ext['tpl'];
}
function forwardPathToName($forward_path)
{
$forward_path = preg_replace('/^\/+/', '', $forward_path);
$forward_path = preg_replace(sprintf('/\.%s$/', $this->getExt('tpl')), '', $forward_path);
return $forward_path;
}
こうすれば、$forward の設定をいちいち行わなくて済む。
