Fast CakePHPちょっと見た。

内容的には、PHPフレームワーク完全マスターとさほど変わりない。
ただ、説明はFast CakePHPの方が詳しいので、
初心者にはオススメかも。本自体が薄いので、読むのもそんなに苦にならない。

1.1系がメインぽいけど、厚みなら↓。

内容は見てないので、なんとも。評価は4つ星なので、悪くはないと思う。

Fast CakePHPを見て思ったこと。
オールインワンの敷居はそんなに高すぎるもんじゃないのかもしれない。
確かに前提知識として、ActiveRecordやらMVCやらを知っておくと非常にスムーズに習得できるけど、
ただ使う薄いユーザにとっては、そんなのははっきり言ってどうでもいい。
とりあえず、規約部分と「そうなっている」というのだけ覚えれば、
使いこなす事はできる。
たとえば、Model部分は、DBの基礎とリレーションさえ分かってればそんなに難しくない。
初心者が一人でやるのでなければ、
上級者が、Modeの設定だけしてしまえば、
コントローラで
$this->テーブル名->find();
$this->テーブル名->findAll();
メソッドでテーブルの情報が連想配列で返ってくるよ
と説明すればOKだとおもう。

"ただ"使うぶんには、敷居は低そうな気がするでしょ？

あと、実際いくつかのプロジェクトで使ってみて、思ったのが
やっぱり、デザイナとのやりとりのしにくさ。
viewがphpを生でかけるので、あとでの修正が面倒いとの声があった。
(だからCompileViewを開発してるんだけどね)
smartyと連携をとる試みはなされているものの、
完全に移行できる理由ではなく、多少の努力(修正とタブーがある)は必要みたい。
となると、別のアプローチを模索するしかないのかな。というのが結論。
これさえクリアできれば、かなり使いやすくなると思うんだけどな。

結論として、
これからは、デザイナー指向のフレームワークの需要があるんじゃないかと。そう思う。

Fast CakePHP

CakePHPの新しい本が出たようです。

CakePHPのフォーラムでもスレが立ってますが、
執筆の秋山さんのブログでも告知されてます。

特にこだわったのは「つまずかずにCakePHPを始められること」と「どういうフレームワークなのかを俯瞰（ふかん）できること」でした。

使う人が増えるほど、フレームワークの価値は増大する

http://www.akiyan.com/blog/archives/2008/01/cakephpfast_cak.html

とのこと。
取っ掛かりには良いかもしれませんね。
(本の内容を見てないので何とも言えませんが。)

さて、最近のフレームワークはRoRの影響が強く
オールインワンが主流になってきてます。(特にLL言語)
JavaでもひがさんのSuperAgile然り。
.NETに至っては、正規品(?)にそれ同等のものがある(ASP.NETとか？)　(あんま使ったことないから分からん)
PHPだと、Ethna,ZendFramework,CakePHP,Symfonyとかなり充実。

オールインワンのいいところは設定がほぼ無いことと、
相性問題が発生しないこと。
JavaではまだStruts+Spring+Hibernateは主流なので、
どうしても設定がゴチャゴチャになってしまうのと、
それらの相性で、挙動がおかしくなったりと。
不安要素が付きまといます。

逆に悪いところは、オールインワンが故
習得までに時間がかかることがあること。かな。
CakePHPやZendFW言うなれば、Struts,Hibernate,Springを一気に覚えることに相当します。
(そこまでじゃないか？)
CoCでほぼ自動だとしても、その規約は覚えなくちゃならんので、
やっぱり敷居が高いというのはいなめない。

今回のCakePHPの本は
「どういうフレームワークなのかを俯瞰（ふかん）できること」
を一つの主題としているようなので、
オールインワンってこんなもんか。と早い段階で思えるようになるんじゃないかな？

あ、ちなみに次のプロジェクトで、以前作成した、CakePHP×TeedaのCompileViewを使う予定。
やってく中で機能改善して、最終版を公開する予定です。
(現状公開されているのは、いわばこのプロジェクトのエッセンスで、
　"そのまま"では使い物にならないでしょう。
　現状のものを使う場合は、ソースを自分好みに変更する程度の知識は必要かと。)

そのうちクラス図等などをまとめて公開します。

CompileView改良中。。

使い勝手を良くすべく、CompileViewを改良中。
QuickFormを倣って、freeze機能を付けてみた。
一応出来たんだけど、
CompileViewはファイルの更新日付でキャッシュをするように作ってるので、
静的に書き換えることが大前提になる。

つまり、
freeze offの状態で、キャッシュしてしまえば、
freezeがonになろうがおかまいなし。
freeze offの状態のviewが帰ってきてしまう。
これを打開するには
1.FormHelperを書き換える
2.viewは別に用意する。input.htmlとconfirm.html(中身は一緒でfreezeのパラメタだけ違う)
3.if文をCompileView処理時に突っ込み、freeze onとoffのものを作ってしまう。
のどれか。

1は論外だとして、
2が妥当かと思ったりする。
確認画面は入力画面とまったく同じになることはたまにあるくらいで、
確認ボタンが完了と戻るボタンになったり、
パンくずが変わったり、画像のアップロードとかがあるformは
アップロード画像をプレビューしたりとそのまま置き換えれば良いってもんじゃない。
なので、できるだけ楽をして作れるようにするのが妥当かなと思うわけです。

となると、入力画面をパチってきて、
確認画面をちょちょいと直すのが一番てっとり早い。

とりあえず、上の要件を満たすfreeze機能はほぼ出来てるので、
近々サンプルと共に公開する。

これつけれ！とかこうした方が良いんじゃね？なんて意見があれば
コメントまで、気まぐれで対応するかも。