{literal} 〜 [/literal}
で挟むとその間にあるものは、Smarty の構文解析を行いません。
互換性を考えないのであれば公式マニュアルにあるように left_delimiter と right_delimiter を {, } から、<!–{, }–> に変更するというのもスマートです。ただしその場合、タグの属性の一部を変数にいれる使い方をすると、ソースはプレーンな HTML ではなくなりますが..。
<option value=1 {checked}>
参考:
– Smarty の構文解析を回避する(Smarty 2.6.3 マニュアル)
PHPプログラムからrequire/includeの検索パス（include_path）を上書き、追加するには、set_include_path()を使います。
例えば、ディレクトリ “/path/to/include/” をrequireの検索対象に追加する場合は以下のようにします。
<?php set_include_path(get_include_path().PATH_SEPARATOR."/path/to/include/");
または ini_set()を使う方法もあります。
<?php
ini_set('include_path', ini_get('include_path') . PATH_SEPARATOR . '/usr/lib/pear');
get_include_path() や ini_get(‘include_path’) は、今のinclude_path 設定を取得している関数呼び出しです。
set_include_path() や ini_set() は既存設定を（追記ではなく）上書きするため、追記にするために既存設定を取得して、新しい設定をつなげて足して、追加としています。
PATH_SEPARATOR はPHPの定義済の定数で、include_pathでパスを繋げるための文字が入ります。
（Windowsならセミコロン、Mac OSやLinuxならコロンが入ります)
– PHP コード変換機(phpspot.net)
オンラインツール。PHP の文法を解釈して、PHP ソースコードを読みやすいように色づけした HTML を生成してくれます。
PHP のビルトイン関数については、phpspot の関数マニュアルページにリンクされます。
近年は MVC というと PHP の Mojavi とか Java の Struts 等の MVC フレームワークが取りざたされます。しかし MVC フレームワークと聞くと何か難しい、MVC も概念は分かるけど使うのは難しい、という人もいるんじゃないでしょうか。
というわけで、フレームワークを一切使わず、MVC モデルの Hello, world 的スクリプトを PHP で書いてみました。
名前を入力してその人に挨拶する、次のようなコードがあります。これを MVC の構造に変えてみましょう。
nameform.php:
<html>
<head><title>名前入力</title></head>
<body>
<form action=”” method=”POST”>
名前:<input type=”text” name=”name”><br>
<input type=”submit” value=”挨拶”><br>
</form>
<?php
if(!empty($_POST[‘name’])){
$name = htmlspecialchars($_POST[‘name’]);
echo “こんにちは、$name!!”;
}
?>
</body>
</html>
これに簡単な MVC モデルを適用すると、次のようになります。
nameform.php:
<?php
// 挨拶プログラム(Controller)
// 機能部分を読み込み
require_once ‘include/greeting.inc’;
// 挨拶を実行し、出力用に特殊文字をエスケープする。
$result = htmlspecialchars( greet() );
// 結果を表示。
require_once ‘template/nameform.html’; // View を呼び出し。
?>
include/greeting.inc:
<?php
//
// 挨拶プログラムの Model (ドメイン固有)
//
require_once dirname(__file__).’/request.inc’; // パラメータ取得用
/**
* 名前を取得し、挨拶する。
* @return string 挨拶の言葉。処理できなかった場合空文字
* @access public
*/
function greet(){
$name = get_parameter(‘name’);
if($name){
return greet_to($name);
} else {
return;
}
}
/**
* 指定した相手に挨拶する。
* @param string $name 相手
* @param string 挨拶の言葉
* @access private
*/
function greet_to($name){
echo “こんにちは、$name!!”;
}
?>
include/request.inc
<?php
//
// パラメータ操作用ユーティリティファイル (非ドメイン固有 Model)
//
/**
* 指定した名前を持つリクエストパラメータを取得する。
* 存在しない場合は空文字を返す。
* @access public
* @param string $key 取得したいパラメータの識別名
* @return string パラメータの中身。存在しない場合空文字
*/
function get_parameter($key){
return empty($_POST[$key])? : $_POST[‘key’];
}
?>
template/nameform.html:
<!– 名前入力フォーム(view) –>
<html>
<head><title>名前入力</title></head>
<body>
<form action=”” method=”post”>
名前:<input type=”text” name=”name”><br>
<input type=”submit” value=”挨拶”><br>
</form>
<!– 処理結果 –>
$result
?>
</body>
</html>
どうでしょう？
PHP のコード(モデル、コントローラ)と HTML デザイン(ビュー)がしっかり分離できているのが確認できると思います。また、メインルーチン(コントローラ)と関数(モデル)が別ファイルに分けられていて、関数はさらに汎用的なもの(共通モデル)と挨拶プログラム固有と思われるもの(ドメイン固有モデル)とに分けています。
この程度であればメリットは感じず、ただ書く量が増えるだけに感じると思いますが、これが数百行を超えると大きく変わってきます。
– ビューとコントローラを分けることでデザイナとプログラマの作業分担をしやすくなる。
– コントローラとモデルを分けることで同じ処理を行う時にコピーペーストを行う必要がなくなる。
– さらにモデルをドメイン固有モデルと共通モデルとに分ける事で、他のシステムで使い回しても影響がない部品(＝共通モデル)が明確になり、再利用性が高まる。
感覚が掴めそうな方は、サンプルに挙げた挨拶プログラムを基本として、次のように改善していってみましょう。
– ビューに PHP コードでなく Smarty を使うようにする。その場合、htmlspecialchars はやめ、代わりに Smarty の ${result|escape} など escape 修飾子を利用するといいでしょう。
– モデルを関数ではなくクラスにする。
– コントローラに処理を書いていく時は、処理を関数として抽出できないか目を光らせておきましょう。抽出できそうな時はドメイン固有モデルとして抽出、移動しましょう。
– ドメイン固有モデルが増えてきた時は、汎用的な共通モデルにできないか考えましょう。つまり、モデルのコードを一切変更することなく、他のシステムで利用可能かどうか考えましょう。他のシステムでも有用な機能があるのに、他のシステムで使うには変更の必要がありそうなときは、変更せずに済む方法を実装し、共通モデルにすることも検討してみましょう。(内部パラメータの setter を用意する、設定ファイルを読み込めるようにするなど)
なお、PHP での MVC モデリングについては Zend コーディング指針の MVC の項も参考になります。
参考:
– Smarty(日本語マニュアル)
Zend Japan PHP コーディング指針
Zend Japan PHP セキュリティ指針
いずれも、ゼンドジャパン株式会社 技術情報コンテンツのひとつです。
これは PHP プログラマ必読のドキュメントですね。
Q. Linux + Apache + PHP + eAccelerator の環境で apache が次のエラーを出して動かなくなりました。
$tail -f error_log
PHP Warning: [eAccelerator] Can not create shared memory area in Unknown on line 0
PHP Fatal error: Unable to start eAccelerator module in Unknown on line 0
[Thu Feb 23 09:26:31 2006] [warn] pid file /usr/local/apache_1.3.34/logs/httpd.pid overwritten — Unclean shutdown of previous Apache run?
PHP Warning: [eAccelerator] Can not create shared memory area in Unknown on line 0
PHP Fatal error: Unable to start eAccelerator module in Unknown on line 0
A. このエラーが出た場合、原因はここの次の FAQ に書いてあるケースの可能性があります。
Q: I’m using linux 2.6 kernel and eAccelerator doesn’t get loaded when the shm_size is set to value bigger than 32mb. Php gives this warning:
PHP Warning: [eAccelerator] Can not create shared memory area in Unknown on line 0A: The default shared memory size for the 2.6 kernel is 32mb. You can change this size by setting /proc/sys/kernel/shmmax to the disired maximum value. You can do this by echo VAL > /proc/sys/kernel/shmmax or add the line kernel.shmmax=VAL to /etc/sysctl.conf so you don’t have to set it manualy every time you reboot.
カーネルの共有メモリ制限(デフォルト32MB)を超えて、eaccelerator.shm_size を設定したのが原因でした。php.ini で
eaccelerator.shm_size=32
のように範囲内に押えるか、あるいは FAQ にあるように
# cat /proc/sys/kernel/shmmax
33554432
を、
# expr 64 “*” 1024 “*” 1024 > /proc/sys/kernel/shmmax
のように、バイト単位で適切に上限を設定してカーネルごとリブートすれば解決します。
portupgrade 利用中に以下のエラーに遭遇。
# portinstall devel/pear
… (中略) ..
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 56 bytes) in /tmp/gopeypYZxF/PEAR/Registry.php on line 1006
Allowed memory size of 8388608 bytes exhausted (tried to allocate 5 bytes)
*** Error code 1
Stop in /usr/ports/devel/pear.
*** Error code 1
… (以下略)..
portinstall 中のことで一瞬何かと思いましたが、PHP 周りで 8388608bytes = 8M 制限といえば、php.ini の次の設定ですね。
memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
これを、一時的に 16M とかしたら問題なくインストールできました。
SJIS 以外は SET NAMES クエリでの設定で解決するが、SJIS ではクエリでは解決できない。
結論からいうと、
mysql –default-character-set=sjis [ -u username [ -p ]] […]
のように、クライアントでの接続時に –default-character-set=sjis と明示してやるだけで解決する(SET NAMES .. は不要)。my.cnf の [mysql] の項目に sjis と設定してやってもよい。
PHP でも my.cnf を見ているらしい。PHP ではこれ以外の妥当な設定の手段がないもよう。
現在は、一部のコードでのみ対応したい場合は、自分でラッパ関数を作ってやるのがよさそう。PEAR::DB の prepared statement 構文を使う場合は ujis (EUC_JP)として通信させてやらないとうまくいかなかった。
詳しく書くと、DB_Common::prepare で呼び出している内部関数で非 UTF8 のつもりでエスケープ処理を行うため、事前エンコードをすると文字が壊れてしまうのが原因。EUC-JP だと、ASCII コードに互換性があるためエスケープ処理で文字が壊れないのでエンコード後のエスケープでも問題ない。
//
// 単純なサンプル。実用コードではありませんよ。
//
$con->query(‘SET NAMES ujis’);
echo dec( $con->getOne(enc(‘SELECT description FROM product WHERE name = ?’), enc(array(‘苛性ソーダ’))) ) ;/**
*
*/
function dec($val){
return mb_convert_encoding($val, mb_internal_encoding(), ‘EUC-JP’);
}
/**
* エンコード。クエリを実行する前の前処理。
* @param string $val 変換対象の文字列
* @return string DB クエリの文字コードに変換した文字列
*/
function enc($val){
return mb_convert_encoding($val, ‘EUC-JP’);
// $val は mb_internal_encoding() の文字コード。それ以外も
// 受け付ける場合, 第三引数を ‘auto,UTF-8’ 等にしておく。
}
参考:
– OSS Web – 接続キャラクタセットの変更
ここにあるとおり、show variables like ‘character\_set\_%’ では同じなのに、実際は内部的には違うのがなんとも。