リファクタリングメモ
放っておくと事態は悪化するので、重い腰を上げて直すことにした。
まずはファイル名の変更。
Hoge.class.php を Hoge.php にする。
そしてテストコードを書きながら気になった部分をリファクタリング。
mapleみたいにコアを差し替えたりするわけじゃないので、今後はコアでコンテナを利用している部分を減らす方向で。
あとディレクトリ構成の変更。
mapleっぽくプロジェクトのwebappを検索してからフレームワークのwebappを検索。できればいいな(予定
それから定数。
function define_once($key, $value, $flag=false){ if (!defined($key)) define($key, $value, $flag); }
こういう設定の仕方をしておく。
そうすると、index.phpでは基本ファイルを読み込むだけでいい。
定数の定義は必要な箇所だけする。
なければ
<?php // index.php require_once 'Laiz.php'; ?>
これだけで動くように。
mapleを入れてみる
今度のジェネレータはシェルスクリプトになってるぽいので、pearコマンドで入れてみる。
/usr/bin にmapleコマンドがインストールされた。
書いてある通りにやるとwebappは出来るんだけども、、あれ?htdocsってどうやって作るんだっけか。
generator_name のリストも欲しいな。。
正式バージョンになるまで待とうかな。
段々複雑になっていくと、濃いユーザは使いやすくなって初心者は入りにくくなるという感じがするなぁ。
向かう方向としては当然なんだけども。
取り敢えずindex.phpからControllerが呼ばれるとして
- ActionChainの取得
- リクエスト変数からアクションチェーンへアクションの追加
- アクションチェーンループ
- ConfigUtilsの取得と実行
- アクションチェーンの取得(依存関係を示す意味でも引数で渡した方がいいんじゃないだろうか)
- 現在の設定の読み込み
- 階層ごとにファイル名を設定してparse_ini_file()
- 取得した値をmergeなど適切に設定
- フィルタチェーンの取得
- ConfigUtilsを引数にしたフィルタチェーンの初期化(こっちは引数で渡している)
- フィルタチェーンの実行
- ...
- ConfigUtilsの取得と実行
で、今回見たかったのはこの辺の処理に入る前の段階だ。
前のindex.phpを参考に見てみる。
- index.phpの処理スタート
- webapp/config/maple.inc.phpの読み込み
- 定数の設定
- GlobalConfig::loadConstantsFromFile(dir, GLOBAL_CONFIG)の実行
- テンプレートの設定
- コントローラの読み込み
- コントローラの実行
頭がこんがらがってきた。。
取り敢えず休憩。。
コンテナ
何だか違和感が無くならない。
普通のコンテナを使ったことがないのにDIコンテナを使おうとしたからだろうか。
どうもグローバル変数的に乱用してる気がする。
これに最初に気付いたのは後からテストコードを書くときで、一つのクラスをテストするのに何個もクラスを呼び出さないとテストできない状態になっていた。
そして今、コンテナの名前を変更したんだけど、変更箇所が多いこと多いこと。
$container = & DIContainerFactory::getContainer();
って至る所に書いてある。
このDIっていうのが嫌なので取ることにしたんだけど、かなり大変だった。
これが変数なら初めに生成するところだけ書き換えれば済んだのに・・。
ということで、もう書き換えないと思うけどメンバ変数に入れることにした。
理想はコアの中でコンテナを使わないこと。
アクションから呼び出される可能性のあるものはコンテナに入れてもいいけど、コアでしか使わないクラスをコンポーネントとしてコンテナに入れる意味は無さそう。
明確に区別する意味があるかどうかはまだ分からない。
リファクタリングしたい・・
クラス名とファイル名を書き換えたい衝動に駆られる。
しかしテストコードが少ししかない・・。
ファイル名を書き換えるならテストコードがあったとしてもそれも書き換えないとダメか。
- hoge.class.php => hoge.php
- DIContainer => SimpleContainer or LaizContainer
- Action.php => ??
- hoge.dicon.ini => hoge.ini
- html/ => templates/
- Filter/ => Filters/
あとテストコードをきっちり書いて・・・
品質を上げようとするとやること沢山だ。
コンポーネントもフレームワークのリポジトリに入れてしまっているが、分けた方がいいかもしれない。
毎回全部まとめてリリースする場合は一緒にした方が都合がいいのかな。その辺のノウハウもいまいち分からない。
細かな修正は一旦置いといて名前をごっそり変えるかなぁ・・。
セキュリティとmod_rewriteの代わり
http://www.jpcert.or.jp/wr/2006/wr063001.txt
mod_rewriteに関する脆弱性。
こういうのでDebianが載っていると、何となく安心できる。
mod_rewriteを使わずにPATH_INFOを使う設定
<VirtualHost *> DocumentRoot /home/foo/public_html ServerName foo.example.com CustomLog /var/log/apache2/access.log combined RedirectMatch ^/Controller$ http://foo.example.com/Controller/ <LocationMatch ^/Controller/> ForceType application/x-httpd-php </LocationMatch> </VirtualHost>
LocationMatchで拡張子がなくてもPHPとして動くようにして、スラッシュを伴わない場合はリダイレクトさせる。
[PHP][フレームワーク] フレームワーク諸々
PHPのフレームワークについて
PHP Framework: CakePHP のおいしい食べ方
CakePHP のおいしい食べ方
分かり易い。
私も他のフレームワークとの違いを言えるくらいに調査出来てればいいんだけど・・。
取り敢えず今後作ったページに
powered by Laiz
とか書いていくと少しは有名になったりして。
HTTP_Download
トラックバックをもらったので調べてみる。
PEARって全然詳しくないので基本的なパッケージも知らない。
HTTP_Downloadはファイルを送出するためのものっぽい。
他にもHTTP_*には便利なものが沢山。
だけど、使う必要があるのかどうかは分からない。
前にファイルをダウンロードさせるスクリプトを書いたけど、それを見てみるとheaderを3行、あとは
$fp = fopen($file, 'r'); echo fread($fp, $filesize); fclose($fp);
とやっていた。
ファイルサイズが大きければループで少しずつ読み込めばいい。
10行未満のコードを自分で書くか、PEARをインストールして3行くらいのコードを書くか。
そもそもなんでHTTP_Downloadに1000行もあるんだ?って思って見てみると
っていうのをやってる。
圧縮して送ったりアクセスが多い場合はPEARを使った方が良さそうだ。
でも他のサーバのユーザスペースに入れる場合、依存関係があるものを一つずつDLしてアップするのは面倒なんだよね・・。
共通のパス(/usr/share/phpとか)を使わずにインクルードパス(/home/user/libsとか)にまとめてアップできる環境にすべきなのかな。