PHPのテクメモ

PHPはその用途によって大きく3つに分類される。それらはDSO版（モジュール版）、CGI版、CLI版だ。

DSO版はおそらくPHPで一番一般的な使い方で、PHPプログラムがapacheのモジュールとして組み込まれたPHPエンジンで解釈され実行される。一般的なレンタルサーバはたいていコレだ。

CGI版はPHPをCGIとして動作させるタイプだ。たいていはプログラムの一行目にCGI版PHPプログラム本体のパスを指定して実行させる。

CLI版PHPはコンソールにログインして実行するプログラムで使用されるものだ。CGI版とCLI版は基本的に似たようなものだが、CGI版はHTTPヘッダを出力するが、CLI版は出力しない点が異なる。以前はCGI版とCLI版の区別があいまいだった感があるが（厳密に区別はされていたのだろうが、使用者側での区別があいまいだったと思う）、現在は情報も多くなってきている。

さてCLI版PHPはコマンドラインからPHPプログラムを実行するわけだから、ウェブで（DSO版で）引数指定をする際の?hoge=fugaみたいな方法は使わない。当然コマンドラインから実行するわけだから、以下のような記述になる。

/usr/local/bin/php-cli ./hoge.php fuga piyo

上記はhoge.phpに引数fuga、piyoを与えて実行させている。これらの引数をPHPプログラム内で取り扱うためには以下のように指定する。

$_SERVER[‘argv’]

戻り値は配列となり、最初の値はプログラム本体（hoge.php）、2番目以降は引数として与えられた値、となる。具体的には上記の戻り値は以下のようになる。

array(0=>’hoge.php’,1=>’fuga’,2=>’piyo’)

よく似た環境変数で$_SERVER[‘argc’]というのがある。こちらは引数の個数を返すので、上記の場合の戻り値は「3」となる。

PHPでバックグラウンド処理を実施する場合は、上記のような知識が必要になる。

通常PEARコマンドでPEARパッケージをインストールするときは以下のようにコマンドをうつ。

pear install HTML_QuickForm

上記でインストールできるのは安定版（stable）であって、インストールしたいパッケージのバージョンがまだベータ（beta）とかアルファ（alpha）だと「インストールに失敗しました」と表示されてインストールすることができない。では、どうするか。

pear install HTML_QuickForm2-alpha

パッケージ名の後ろにハイフンとbetaやalphaと指定すればよい。設定そもそもで「ベータでもアルファでも何でも来い」ともできるのだが、安定版でないものに関しては、その都度確認しつつインストールしたほうがいいだろう。

Zend_Configは、設定ファイルを読み込むためのライブラリだ。通常PHPで設定ファイルを用意する際、自分はこんな具合に書いている。

define(‘ADMIN_MAIL’,’admin@example.com’);
define(‘ADMIN_PASSWORD’,’hogehoge’);

define文の列挙だ。これはこれでいいのだが、設定ファイルを素人な方に編集させるのには気が引ける。そんな場合に便利なのがZend_Configだ。Zend_Configにはiniファイル形式の設定ファイルを取り扱うZend_Config_IniとXML形式の設定ファイルを取り扱うZend_Config_Xmlとがある。当然、直感的にわかりやすいZend_Config_Iniを使う。

設定ファイルにはWindowsのiniファイル等でおなじみの書式を使って設定を記述する。

[admin]
mail=admin@example.com
password=hogehoge

[datasource]
db.host=localhost
db.name=hoge
db.user=fuga

上記の設定が書かれたファイルをconfig.iniというファイル名で保存するとZend_Config_Iniを使って以下のように呼び出す。

$configObj = new Zend_Config_Ini(‘config.ini’,NULL);

これだけで、$configObj->admin->mailなんて具合にオブジェクトのプロパティとしてアクセスできるようになる。db.hostみたいにドットで区切られている場合は、$configObj->datasource->db->hostみたいな感じになる。

自分の場合は、オブジェクトではなく、関数を一つかませて、オブジェクト形式から配列形式に変換して使用している。

function _readConfig($configObj)
{
  $configs=array();
  foreach($configObj as $configKey => $configValue){
    if(is_object($configValue) || is_array($configValue)){
      $configs[$configKey]=_readConfig($configValue);
    }else{
      $configs[$configKey]=$configValue;
    }
  }
  return $configs;
}

さらにZend_Registryとセットで使うと「初期設定を読み込んで、共通変数にセット」なんてことがすぐにできる。これも便利だ。

異なるクラス間で共通の値を持ちまわりたいときは苦労する。引数で渡すか、グローバル変数として定義するか、方法はいろいろあるが問題もある。

・引数で渡す
いろいろなメソッドで使う場合、その都度毎回引数で渡すのは面倒。
・グローバル変数として定義する
どこかで変数名がバッティングしないかちょっと不安。

そんなのを解決してくれるのがZend_Registryだ。使い方は超簡単。

・変数の登録
Zend_Registry::set(‘変数名’,’変数の値’);

・変数の呼び出し
Zend_Registry::get(‘変数名’);

上記のように直接メソッドを呼んでもいいし、オブジェクトを生成してからメソッドを呼んでもいい。何より、非常に簡単というのが最高にいい。ますますZendに惹かれる今日この頃だ。

先日作ったZend Frameworkウェブアプリだが、実は気になっている部分が一つ。Smartyの使い方というか配置だ。Zend Frameworkのマニュアルには、Smartyを組み込むためのViewスクリプトだけが紹介してある（参照）。しかし、これは単なるスクリプトであって、実際の組み込み方はどこにも書いてない。厳密に言うと、組み込むのはrequireしてオブジェクト生成だが、フレームワーク内での教科書的な組み込み方に関する記述がないのだ。

とりあえず、自分ではZend_Controller_Actionを継承したbaseControllerを作成し、その中でpreDispatchメソッドを定義して、以下のように書いておいた。テンプレートの配置場所とかキャッシュ生成場所とかもルールにのっとって配置するようにした（その他設定はお好み次第で）。

public function preDispatch()
{
  $controllerName  = ucfirst($this->getRequest()->getControllerName());
  $viewDir    = dirname(__FILE__).’/../views';
  $templates_dir  = $viewDir.’/scripts/’.$controllerName;
  $extraParams  = array();
  $extraParams[‘compile_dir’]    = $templates_dir.’/templates_c';
  $extraParams[‘plugins_dir’]    = array(‘plugins’,$viewDir.’/plugins’);
  $extraParams[‘left_delimiter’]  = ‘<{';
  $extraParams[‘right_delimiter’]  = ‘}>';
  
  $this->view    = new Private_View_Smarty($templates_dir<$extraParams);
  $this->view->getEngine()->load_filter(‘pre'<‘convert_encoding’);
}

ただコレだけだと実はNG。例えばVIEWの必要がないアクションを用意した場合、これを組み込んだ基底クラスを継承すると問題が起きる。このメソッドの定義上、該当するテンプレートディレクトリやキャッシュディレクトリが存在しないとおかしなことになるわけだ。

そう考えると、いろいろなエラー制御も含めて、コード自体も設置方法自体も検討しなくてはいけない。悩ましい。

どうせなら、本当に教科書的なものを用意してくれればよかったのにね。