phpの最近のブログ記事
スクリプト内に以下記述を行うことでロケールの変更が可能。
Configure::write('Config.language', 'ja');
参考サイトの記述を元に bootstrap.php に
define('DEFAULT_LANGUAGE', 'en');
とかしても上手くいかないので、そんな時は手動で設定すればよい。
このサイトを参考に
extract コマンドで po ファイルを生成するところまではいけたけど、
言語の切り替えが上手くいかなくてハマリ中。
どうやっても日本語になってしまう。
まあいいけど。
あと、最初に生成されるファイルが default.pot で、それをそのまま
local/jpn/LC_MESSAGES にコピーしたら動かなくてハマった。
default.pot → default.po に改名しなきゃなのね。
※僕の cake は 1.2.0.5427alpha。
php の画像処理ライブラリのasidoが便利そうだったのでひどい web アプリを作ってみた。
url でサイズと画像を指定したら、そのサイズでその画像を出力するアプリ。
まず、元画像 500x334
これを、以下のような url でアクセスした時の画像
動作の説明がめんどいので、さらっと。
- 元画像は ドキュメントルートからの絶対パス指定でも、http:// から始まる絶対パスでもok
- url で指定されたサイズにリサイズする
- 縦横比が異なる場合は、リサイズした上で画像の中心から指定サイズ分トリミングする
- 元画像より大きいサイズを指定した場合は無視される
- 本来は一度生成した画像はこの辺に書き出される→ http://pm11op.xii.jp/pm11op/anysizenizer/img/thumbs/test/100x100/
- けど、借りてるサーバに得体の知れない画像が生成されるのは嫌なので、表示直後に unlink する富豪っぷり。
- 中身は CakePHP と asido で動いてますよと。
一番下からダウンロードできますが、
実際に使用した際に発生したいかなる不利益も自己責任で処理してください。
ちょっと考えただけでも以下の問題点・改善すべき点があります。
- 富豪過ぎるので、画像もDBに格納して管理する －扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含めを参考に mod_rewrite でキャッシュぽくしたら、案外使えると思う
- とはいえ、ループで大きい画像を 1x1 ～ 5000x5000 とかされたらひどい目に合うと思うので、指定サイズ以外は無視するとかの処理はすべきだと思う。
CakePHP をいきなり実践投入して2ヶ月程たった。
最近は Web アプリ作る時に当たり前のように Ajax 使うし、
それを当たり前のように要求される。
(要求されるのはほとんどがアニメーションとかの部分であって、特に ajax ではないけど。)
で、それを当たり前のようにこなすに当たり、CakePHP は便利なんだけど、
何が便利かっていうと、 決して php から Ajax コードを記述する、
Ajax helper があるからではない。
せっかくだから Ajax helper を何度か使おうとしたけど、
結局全く使わなかった。(使えなかった)
php から javascript を記述しようとすると、痒いところが多すぎる。
じゃあ CakePHP は何が便利かっていうと、
controller 内 の action で、
$this->layout = '';
こうするだけで、簡単に layout なしの HTML パーツを生成できるから便利。
それを javascritp で受け取って表示するコードなんて、すぐ書ける。
- HTML の生成は PHP が行う
- javascript はそれを受け取って表示する
- それ以外のアニメーションを含む HTML の加工は javascript が行う
それって当たり前のことなんだけど、改めてそう決めておけばメンテナンス性が落ちることもない。ハズ。
下手に Ajax helperを使ってしまうと、
どうしてもある部分では PHPで、ある部分は javascript に書かれてて、
しかもその境界があいまいになっちゃったりする。
関係ないけど javascript HTML テンプレートとか使い出したらいよいよ危ない。
html helper もいろいろあるけど、
html タグを書きたくない病の人向けすぎる。 form 関連だけで十分。
div タグとか img タグとか、そんなもん手で書けばよいと思う。
最近のデザイナーさんは smarty 混じりの html くらいなら普通に手を入れてくれるし。
僕のまわりのデザイナーさんが優秀なだけかもしれんけど。
それが smarty じゃなくて php コードだったらまた話は違ってくると思う。
確かめたわけじゃないけど。
なんでかっていうと、 「<?」これとか「?>」これとかが ぱっと見で html タグと区別しづらいから。
僕自身、PHP 混じり HTML 文見るとイラっとするし。
だから、PHP プログラマはできるだけ HTML 書きたくない病にかかったりするんだと思ってる。
※僕の cake は 1.2.0.5146
CakePHP で /app/tests/cases/ 以下に testCase を作成すると、
App Test Cases でテストの一覧を表示してくれる。
勝手に表示してくれるのはありがたいが、
でもどうせだったら全部まとめて実行したい。
勝手に表示してくれるくらいだから、
全部まとめて取得するメソッドあるんだろうと思ったら、やっぱりあった。
こんな group test を作ると、App Test Groups のところに表示されて、
testCase 全部まとめて実行してくれる。重いけど。
/app/tests/groups/app_all.group.php
class AppAllGroupTest extends GroupTest {
var $label = 'run all app test';function AppAllGroupTest() {
TestManager::addTestCasesFromDirectory($this, APP_TEST_CASES . DS );
}
}
前エントリで書いた、任意の url で任意の controller, action を実行する方法で、
例外が一つある。
url と controller, action のマッピングメモ
それは、既に存在するディレクトリ名を含むマッピングができないという点である。
例えば、既に /blog ディレクトリが存在する場合、
いくら routes.php にこう書いても、 /blog/ へのアクセスで
BlogController は実行されない。
Router::connect ('/blog/:action/*', array('controller'=>'Blog', 'action'=>'index'));
これは、ドキュメントルート直下の .htaccess で以下のように記述されているためである。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</IfModule>
リクエストに該当するファイルやディレクトリが無い場合に限り、
index.php に Rewrite されるのだ。
/blog が既に存在する場合、 Rewrite はされない。
でもどうしてもどうしても /blog で BlogController を実行したい場合は、
/blog/index.php に、以下内容を記述すればよい。
<?php $_GET['url'] = '/blog/';// ドキュメントルート直下の index.php をインクルードする
require('/../index.php');
?>
因みにこのことは .htaccess の↓の行をコメントアウトしたら
実現しそうな気もするが、それは罠である。ムリ。
RewriteCond %{REQUEST_FILENAME} !-d
さらに言えば、静的 html も view ディレクトリ下に配置して、
Cakephp から(例えば pagesController)から呼び出すという方法もあるが、
全ファイルが php になってしまうので、時と場合を選ぶ。
Session を保持しつづけなければならないようなサイトでは、
その方法がよさそうだと思った。
※CakePHP1.2 の話です。
CakePHP で既存の controller, action を任意の url で実行するには
/app/config/routes.php にマッピングを記述すればよい。
例えば、マニュアルには /blog/history/05/june という url で
BlogController の history アクションに 05, june というパラメータを
渡す方法を書いてある。
次の例では、/blog のすべてのURLを、 BlogController に接続します。デフォルトのアクションは、 BlogController::index() になります。
例 4.3. Route の例
connect ('/blog/:action/*', array('controller'=>'Blog', 'action'=>'index'));
Routes の設定
でも実はこれ、特に設定しなくても普通に実行される。
何も設定しなくても、ディレクトリの第一階層は controller として扱われるし、
第二階層は action として扱われる。
そして、それ以下はパラメータになる。
マニュアルで言わんとしてるのは、これが任意の url で可能であるってことだ。
例えば、 /archive/05/june/ という url で上記と同じ action を実行するには、
以下のように記述するとよい。
Router::connect('/archive/*', array('controller' => 'blog', 'action' => 'history'));
また、 /blog ではなく、 /cms 以下全ての url を BlogController に接続するには、以下のようにする。
Router::connect('/cms/:action/*', array('controller' => 'blog', 'action' => 'index'));
ここまでがマニュアルに書いてあることだ。
試してみた限りでは、さらに /archives/something/category/ という url で、
BlogController の category アクションに、 "something" というパラメータを渡すことが可能だ。
こうする。
Router::connect('/archives/:pass/:action/*', array('controller' => 'blog'));
ただし、/archives/something/category/hoge/ としても、 hoge はパラメータとして渡されない。
ぽい。
メモ。
PHP 4 のサポートが年内で終了するとかで。
今のところそんなに思い当たる節が無いので
(いよいよ切羽詰ってからでも間に合うかな？くらいの心当たり)
愕然とするわけではないが、やはりめんどくさい話なわけで。
「われわれの見たところでは、積極的に開発を行っている人はみなすでに移行を済ませている。統計データの数値は、PHP 4ベースのレガシーアプリケーションがたくさんあるために歪められてしまっている。そういったアプリケーションは現状のまま稼働しているので、誰も変更したがらないからだ」とGutman氏は主張する。「PHP 4」のサポートが2007年末で終了へ
この言い分って、随分暴力的じゃないか。
「統計データの数値は、PHP 4ベースのレガシーアプリケーションがたくさんある」ことを証明しているんじゃないのか。数値を歪めてるってなんだよ、それｗ
しかも「誰も変更したがらない」ってわかってるやん。
- 動いてるスクリプトはさわりたくないのが世の常
- リファクタリングとかいうけど、昔のスクリプトって、本当そんなレベルじゃないのよ。いわゆる php の悪いところ。
- で、その動いたスクリプトを書いた人は往々にして多忙
- 余裕のある人間は、そんなリスクを負うつもりのない人間
- こういうやつは大抵「自分の」書いたプログラムは php4 でも php5 でも動きますとか、人の書いたプログラムは関係無いですとか言い切る
- 予算が発生しない作業なのがそもそも問題
- php4 と php5 を同じサーバ上で共存させるのが面倒(切り替えるのは簡単)な以上、 php4 と php5 で動作するスクリプトを書くのは困難
- そもそも pear って php4 向きでしょ。pear な部分を作り変えるのは、さすがにちょっと。。。
まあそんなこんなで、php5 への移行はやっぱり進んでないと思う。
でも、何とかしなきゃならん状況なんでしょう。
じゃあ、どうするかって話だけど、
いよいよ困ってるような所は、クライアントにリニューアルでも持ちかけりゃいいんじゃね？
予算が発生すれば、それなりに動く人は動くわけで。
php5 に作り変えなきゃいけないわけですが、
単に作り変えても意味無いので、どうせだったらリニュりましょかとか
言えばいんじゃない？(人ごと)
僕はなるべく意識しながら、CakePHP 使ってこうと思います。
実際問題してないけどね、意識。
↓意識するなら、これです。エライ！
http://www.1x1.jp/blog/2007/06/php_php4_to_php5.html
plugin の存在を完全にスルーしてた。
汎用的な controller は plugin として作るべきなのか。
しまった。component として作ってた。
最初は感動するものの、使えば使うほど嫌いになっていく HTML_QuickForm がメンテナンス終了したとか何だとか。
とうとうHTML_QuickFormのメンテナンスが終了してしまった（正確に言うと追加開発が終わっただけでバグフィックスは継続しておこなわれる模様）。
僕にとって、「昔の彼女が結婚しました」みたいな話だ。
あの時はありがとう、どうぞお幸せに。
みんな CakePHP に乗り換えればよいと思う。
こっちのがきっと幸せになれる。
about pm11op
関西でプログラマやってます。
- pm11op at gmail.com
