読者です 読者をやめる 読者になる 読者になる

events.php.gr.jpのイベント管理システムのソースを見て思ったこと

events.php.gr.jpのイベント管理システムのソースが公開されたので、早速中を見てみました。
events.php.gr.jpがcodereposに - /halt/Snapshot


次会の第32回php勉強会で、haltさんがこのシステムについて話をされるので、設置方法等は割愛して、気が付いた点を書きます。

アクション名の指定方法について

アクション名の指定方法は、デフォルトでは、 index.php?action_xxxx=1 という形式のURLになりますが、このイベントシステムでは、PATH_INFOを使用して、URLがスマートになるようになっていました。

http://example.com/index.php?action_event=1
↓
http://example.com/index.php/event

これをさらに、mod_rewriteと組みあせることで、index.phpも隠蔽したりすることが出来るでしょう。
うちでも、最初はいろいろURLがきれいになるように変更したりしていましたが、今では、特別な事情(クライアントの要望や、アクセスログに記録されるURLの形式とか)がない限り、デフォルトのEthna形式を使用しています。


こちらのハック部分は、以下です
app/Event_Controller.php line 278前後

//{{{ _getActionName_Form
/**
 *  フォームにより要求されたアクション名を返す
 *
 *  @access protected
 *  @return string  フォームにより要求されたアクション名
 */
function _getActionName_Form()
{
    isset($_SERVER['PATH_INFO']) && !empty($_SERVER['PATH_INFO']) ?
        $arr = explode('/', $_SERVER['PATH_INFO']) :
        $arr = false;
    
    return $arr[1];
}
//}}}

テンプレートの切り替えについて

テンプレートの切り替えを etc/event-ini.php 内で指定したテンプレートファイルを使用するようになっていました。

'theme' => 'phpgrjp',


テンプレートディレクトリを切り替えている場所。
app/Event_Controller.php line 288前後

function getTemplateDir()
{
    $template = $this->getDirectory('template');
    $config = $this->getConfig();

    if (is_dir($template . '/' . $config->get('theme'))) {
        return $template . '/' . $config->get('theme');
    } else {
        return $template . '/event';
    }
}


この仕組みが用意されているので、デザインのみ作成して配布。のようなことが出来るようになっています。

ログインについて

ログインに TypeKey を使っていますが、そちらは、次回のphp勉強会での話しに期待するとして、authenticate でのログイン状態チェックをしているクラスを継承するという形式は、いま使っている形式と同じでした。

リダイレクトについて

AppAction内で、リダイレクトする箇所がありますが、header関数や exitをしてしまうと、テスト時にもそこで止まってしまうので、なんらかの対応が必要です。

app/Ethna_AuthActionClass.php 内のリダイレクトしてっぽい箇所がありましたが、使っているクラスが見つけられませんでした。。。

Aero_Util::move($this->signout_url, "5");
exit;

Aero_Utilって、どこにあるんだろう?

sqlite、DB接続について

データベースにsqlite2を使用し、接続には adodbを使用していました。
Ethnaには、デフォルトで使用しているDB接続は、PEAR DBですが、他にも Ethna_DB_ADOdb.php が用意されています。
こちらを継承して使用していました。


違和感のあった点としては、Ethna_DB_ADOdbクラス を継承した Event_DBクラス内で、個別データ取得のメソッドが書かれていました。
規模の小さなアプリケーションでは、ここに書いても問題は出ないと思いますが、テーブル数が多くなったり、データ取得のパターンが増えると、[appid]_DB.phpのサイズが肥大しそうだなぁと思いました。
もちろん、AppManager内やAppAction内でもSQLを直で書いているので、DB接続が分散している印象があります。


ADOdbは今度使ってみようと思います。


で、肝心のDBですが、いろいろ試行錯誤して sqlite2 と sqlite3 を同居させて、変換をさせようとしたのですが、うまくいきませんでした。

$ sqlite event.db.default .dump | sqlite3 event.db
SQL error: near "column": syntax error
$ sqlite event.db.default
SQLite version 2.8.17
Enter ".help" for instructions
sqlite> .schema system
CREATE TABLE system (
id INTEGER PRIMARY KEY,
column VARCHAR,
value VARCHAR,
edited_at TIMESTAMP
);

column というカラム名が sqlite3では予約語となっているせいか、うまくいきません。
とりあえず、sqlite2のままで動作テストをしました。
カラム名とかDB名は、予約語に使われそうな文字は使わないほうがいいですね。。

さいごに

こういった、実際にEthnaを使ったアプリというのは、あまり見る機会がないので、見ていて面白かったです。
次回のphp勉強会のhaltさんの発表に期待です。