さて、話は再びCakePHPです。
とりあえずチュートリアルに従って、ブログではなく商品ジャンルの一覧と詳細を作ってみました。
詳細・・・でもないかな。カラムはジャンル名と登録日とジャンルIDだけです。
日本語公式ページの2.0のドキュメントが見られないので、
ちょっと古い1.3のドキュメントを見つつ作業してたのですが、
クラスの命名規則変わっているんですね。
変なところでハマりました。
1.3の時は、posts_controller.phpだったのに、
2.0では、PostsController.phpとしないと自動読み込みをしてくれないみたいです。
規約ベースのフレームワークなのに、クラス名の命名規則を変更するなんて、
なかなか強いことをしますね。
モデルのファイル名も同様にpost.phpからPost.phpに変更されています。
いやぁ、この単数形と複数形が入り混じっている命名規則、いまだに慣れません。
そんな余計なところでハマりつつ、とりあえず意図したとおりに動作してくれました。
めでたしめでたし。なのですが、ここで気になったのがView。
ViewはPostsというディレクトリをつくって、
拡張子を.ctpとして保存します。
indexアクションと対応するテンプレートはindex.ctpとなるのですが、
中身が・・・まんまPHPなのです。
しかもボクの嫌いなendforeachまで使ってくれてます。
Smartyにしようかなといくつか調べていたら、
1.3系でのSmartyViewクラスはありました。
2系は自作している方もちらほらいますが、途中のライセンスがあやふやで使えません。
とりあえずコピーとかする人は、受託開発には向いてないと思います。
適当に対応するとHelperクラスが使えなくなってしまいます。
これはこれで勉強するには痛い・・・。
前にZend FrameworkでSmarty対応やったことありますが、
きれいに対応させようとすると意外と大変。
まだCakePHPは日が浅いのと、特に必要に迫られているわけでもないので、
そんなに改修に時間をかけるのもどうかと思うので、現時点ではそのままにします。
ちょっぴり開発して、GPLライセンスで公開してみようかなとか、
関連する商取引の１％をもらうとか条件つけて公開してみようかなとか、
考えてみましたが、そんな意地悪しても仕方ないのでやめました。
そういうこともあるんで、拾ったソースを適当に使いまわすのには
抵抗があるんですよね。
もう一つひっかかったのが、bakeです。
CakePHPはbakeコマンドで簡単にクラスのスケルトンを作れるのですが、
こいつをSmartyに対応させるのも結構大変そうです。
調べてみるとやっている人もいるみたいです。
実際、CakePHP＋Smartyな環境で開発を進めるなら、これは結構対応必須な個所だと思います。
それにしてもbakeはなかなか便利そうですね。
ボクが作ったフレームワークの発想と近いものを感じます。
そういえば、数年前にそんな話を会社の子から聞いたような聞かなかったような・・・。
まぁ、プラグインも含めて設定ファイルで組み込みできるようにして、
設定ファイルをGUIベースで設定できたので、やっぱり今考えてもよいフレームワークでしたね。
当時やりたかったことはプログラマからオペレータへの作業の移管による、
ボトルネックの解消と開発コストの減少。
一定の成果は出したつもりですが、いかんせんドメインが小さかったなと思います。
もっとも、同じ発想でオープン化すると、エンジニアの首を絞めるだけなので
そんなことは今でもしたいと思いません。難しいテーマです。
さて、もう少しCakePHPのままでいろいろ触ってみたいと思います。
とりあえずチュートリアルに従って、ブログではなく商品ジャンルの一覧と詳細を作ってみました。
詳細・・・でもないかな。カラムはジャンル名と登録日とジャンルIDだけです。
日本語公式ページの2.0のドキュメントが見られないので、
ちょっと古い1.3のドキュメントを見つつ作業してたのですが、
クラスの命名規則変わっているんですね。
変なところでハマりました。
1.3の時は、posts_controller.phpだったのに、
2.0では、PostsController.phpとしないと自動読み込みをしてくれないみたいです。
規約ベースのフレームワークなのに、クラス名の命名規則を変更するなんて、
なかなか強いことをしますね。
モデルのファイル名も同様にpost.phpからPost.phpに変更されています。
いやぁ、この単数形と複数形が入り混じっている命名規則、いまだに慣れません。
そんな余計なところでハマりつつ、とりあえず意図したとおりに動作してくれました。
めでたしめでたし。なのですが、ここで気になったのがView。
ViewはPostsというディレクトリをつくって、
拡張子を.ctpとして保存します。
indexアクションと対応するテンプレートはindex.ctpとなるのですが、
中身が・・・まんまPHPなのです。
しかもボクの嫌いなendforeachまで使ってくれてます。
Smartyにしようかなといくつか調べていたら、
1.3系でのSmartyViewクラスはありました。
2系は自作している方もちらほらいますが、途中のライセンスがあやふやで使えません。
とりあえずコピーとかする人は、受託開発には向いてないと思います。
適当に対応するとHelperクラスが使えなくなってしまいます。
これはこれで勉強するには痛い・・・。
前にZend FrameworkでSmarty対応やったことありますが、
きれいに対応させようとすると意外と大変。
まだCakePHPは日が浅いのと、特に必要に迫られているわけでもないので、
そんなに改修に時間をかけるのもどうかと思うので、現時点ではそのままにします。
ちょっぴり開発して、GPLライセンスで公開してみようかなとか、
関連する商取引の１％をもらうとか条件つけて公開してみようかなとか、
考えてみましたが、そんな意地悪しても仕方ないのでやめました。
そういうこともあるんで、拾ったソースを適当に使いまわすのには
抵抗があるんですよね。
もう一つひっかかったのが、bakeです。
CakePHPはbakeコマンドで簡単にクラスのスケルトンを作れるのですが、
こいつをSmartyに対応させるのも結構大変そうです。
調べてみるとやっている人もいるみたいです。
実際、CakePHP＋Smartyな環境で開発を進めるなら、これは結構対応必須な個所だと思います。
それにしてもbakeはなかなか便利そうですね。
ボクが作ったフレームワークの発想と近いものを感じます。
そういえば、数年前にそんな話を会社の子から聞いたような聞かなかったような・・・。
まぁ、プラグインも含めて設定ファイルで組み込みできるようにして、
設定ファイルをGUIベースで設定できたので、やっぱり今考えてもよいフレームワークでしたね。
当時やりたかったことはプログラマからオペレータへの作業の移管による、
ボトルネックの解消と開発コストの減少。
一定の成果は出したつもりですが、いかんせんドメインが小さかったなと思います。
もっとも、同じ発想でオープン化すると、エンジニアの首を絞めるだけなので
そんなことは今でもしたいと思いません。難しいテーマです。
さて、もう少しCakePHPのままでいろいろ触ってみたいと思います。