本家サイトにある「未定義のアクションが指定された場合に特定のアクションを実行する」で、定義されていないアクションのリクエストがあった場合にエラーページを返すようにする。
これ、本家の説明が少しわかりにくい（ように思う）んですけど、要するに /path/to/project/www/index.php 内を修正します。
Project_Controller::main(‘Project_Controller’, ‘index’, ‘undef’);
上記のように、第３引数に定義されていないアクションのリクエストがあった場合に実行するアクションを定義する。
そして、/path/to/project/app/action/Undef.php を作成。
これで定義されていないアクションをリクエストすると undef が実行されるものの、何故か WARNING が出力されてしまう。
WARNING 出ちゃうとみっともないんだけど。何か違うのかなぁ。
Ehana の Validator には複合チェックというのが存在するらしいが、今はまだドキュメントが未整備状態。
パスワードを入力してもらった際に確認用のパスワードと入力値が同じかの検証をしようと思ったけど、ドキュメントがない為に自分で適当に考える（今はソース読む気力なし）。
PEAR::HTML_QuickForm でいうところの HTML_QuickForm::addRule() の compare である。
カスタムチェックでごにょごにょと以下のような感じで動いた。
class Sample_Form_Regist extends Ethna_ActionForm
{var $form = array(
‘cmpPasswd’ => array(
‘name’ => ‘パスワード’,
‘required’ => true,
‘type’ => VAR_TYPE_STRING,
),
‘cmpRepeat’ => array(
‘name’ => ‘パスワード確認’,
‘required’ => true,
‘type’ => VAR_TYPE_STRING,
‘custom’ => ‘compare’,
),
);function compare($name)
{
if ($this->form_vars['cmpPasswd'] != $this->form_vars[$name]) {
$this->ae->add($name, ‘The passwords do not match’, E_FORM_INVALIDVALUE);
}
}}
$this->form_vars[] に取得したいフォーム項目名を決めうちで入れてるだけなんだけど。
条件があるフォーム項目でカスタムチェックしたら、いわゆる複合チェックはできますね。
ほんとうはもっとスマートに出来るんだろうな。
以前エントリした「DB オブジェクトに関して」のやり方で PEAR::DB オブジェクトを使ってロジックを書き進めるが、DB 周りのソースをコピペコピペするのが非常に面倒くさくなってきた（まだ２つしかアクション書いてないけど）。
そこで MT のダイナミック・パブリッシングで採用されている ezSQL を思い出した。
いろんな意味でイー・ジー！これ最強！！
プレースホルダなんていう小粋な技も持ってないぜ！
ezSQL をダウンロードしたら解凍して mysql/ez_sql.php を編集。クラスの中にデータソース直書きの潔さがまたイカス。
define(“EZSQL_DB_USER”, “”);
define(“EZSQL_DB_PASSWORD”, “”);
define(“EZSQL_DB_NAME”, “”);
define(“EZSQL_DB_HOST”, “”);
編集を終えたら以下の感じでデータベースから値を取得。
include_once(‘ez_sql.php’);
$res =& $db->get_results(“SELECT * FROM table”);
foreach ($res as $row) {
$row->id;
$row->name;
}
値がオブジェクトで返ってくるのでわかりやすい＆Smarty との相性もよい。
しかもクラス内でインスタンスの生成をしているので include するだけで使えてしまう気軽さ。
一つ注意としては Ethna のクラス名（PEAR::DB？）とぶつかって怒られてしまうので、自分で適当なクラス名で（ezSQL とか）コンストラクタ・インスタンス生成部分は書き換える必要があり。
ほんとうは Ethna の O/Rマッピング使った方がいいのだろうけど。
Ethna::prepare() で validate しての疑問。
今のままでは GET でも Validation されてしまいエラーメッセージが出る。
REQUEST_METHOD が POST/GET 別での処理はないのかと調べたところ、
Ethnaでは基本的にクライアントから送信されるフォーム値をGET/POST(REQUEST_METHOD)で区別しません。理由は、GET/POSTで振舞いを変えていると思わぬところでダサダサな振舞いをしたり、場合によっては(ここはGETしかこないと思い込んでコードを書いていたりすると)セキュリティホールになる可能性もなくもなくも無いためです
と、本家サイトの下の方に書いてあった。
ポリシーなんで仕方ないなと思いつつ、自分で分岐処理を書く。
Ethna の認証処理に関してメモ。
Ethna では Ethna_ActionClass::authenticate() っていうメソッドがあり、authenticate() → prepare() → perform() という順番で呼び出される。
認証処理は、Ethna_ActionClass を継承して authenticate() にロジックを書いたクラスを用意して、更にそれを継承してアクションを書くのが流儀らしい。
# つまり毎回 authenticate() 書く手間を省く。
ここの認証処理で PEAR::Auth を使おうともくろむ。
適当に Sample_Auth クラスとか作って、authenticate() メソッドをオーバライドするが、PEAR::Auth がどうも上手く動かない。
Firefox の LiveHTTPHeaders で挙動を確認すると、Ethna が Cookie を上書きしているっぽいことが判明。
そこで以下のように Ethna_Session::start() を先に呼び出すと動作する。
$this->session->start();
$a = new Auth(‘DB’, $param, null, false);
$a->start();
けど認証時の Validation とかログアウト処理を考えると結構メンドイ＆ Session 周りの処理が非効率になるので PEAR::Auth は使わない方向。
Ethna_MailSender を継承したクラスからメールを送信してみたら Subject が文字化けした。
メールテンプレートの漢字コードは EUC-JP なので、
mb_internal_encoding(“EUC-JP”);
を記述しておくことで回避。
これを設定しておかないと HTML も文字化けする感じ。
Ethna でデータベースを扱う場合、Ethna_Backend::getDBメソッドを利用してDBオブジェクトを取り出すのが一番簡単なやり方。
Ethna_DB は PEAR::DB を継承しているが、getDB メソッドで取り出したオブジェクトだとプレースホルダーが使えない。
なので、Ethna_DB ではなくて PEAR::DB のオブジェクトを取り出して使うと便利かも。
function perform()
{
$db =& $this->backend->getDB();
$db =& $db->db; // PEAR::DB オブジェクトを取り出す
// …
return ‘index’;
}
PHP ウェブアプリケーションフレームワークの Ethna を使ってみたので覚え書き。
Ethna 0.1.5 をダウンロードして展開。
/usr/local/lib/php 内に配置。同じくして Smarty と PEAR::DB も用意しておく。
ここで PHP 4.4.0 以降を使っている場合はパッチ(Ethna-0.1.5-php44.patch)を当てる必要がある。
# パッチを当てないと Segmentation fault で Apache がお亡くなりになる。
