現在開発でも使っている「1.2.5」のバージョンでも十分開発が可能ですが
「1.3」系はそれを上回るほど、個人的には期待しています（笑

というのも「1.2」系では2つのアプリケーションをCakePHPの設計上1つにまとめることができず
2つの「app」を用意しなければならない状態など、若干の不自由さがありました。
もちろん何でも無理やり1つにすれば良いということはありませんが（笑

捉え方は個人差がありますが、個人的には今回の「1.3」系に早く乗り換えたいと考えています。

ちなみに個人的には以下の機能が「1.3」系で魅力的に見えています（笑

1.「virtual fields」機能
ようやく来たか、という感じです（笑
簡単に説明すると通常は1つテーブル内にあるフィールドはCakePHPで普通に取得すると
存在するフィールドのみデータが取得されます。
しかしデータベース（ここではMySQLで例えます）では、存在するフィールドAとBをくっつけてCの仮想のフィールドに
加工してデータを取得することができます。
今までのCakePHPでは独自にクエリーを記述して取得するしか方法はありませんでしたが、今回のCakePHPでは
モデルに記述することでクエリーを書くことなく実現できるとのこと。
さらにコーディング量が減るのではと期待しています。

2.「Routing.admin」の仕様変更
今までの仕様では「Routing」の設定は1つまででした。
いわゆる「Routing」が「admin」と設定していた場合は「index」と「admin_index」のみとなっています。
さらに別名が必要な場合は「app」自体を分けるか、「Webサービス」機能を使うか（個人的にはまったく利用していません。。。）
になるかと思います。
しかし「1.3」系からは複数設定することが可能です。この変更はかなり大きいです（笑

3.Componentsの仕様変更
といっても大幅な変更ではないようですが、使い勝手が向上した変更のようです。
コンポーネントを作成したことがあるかたはご存知かと思いますが、現在のコンポーネントでは
モデルのビヘイビアのように、初期設定値をコンポーネント設定時には記述することができません。
しかし「1.3」系からは記述することが可能になります。
これは個人的ちょっとほしかった機能で、コンポーネントの開発の幅が広くなりそうです（笑

と特に魅力的に思えた部分ですが、その他にも「Valdation」などなどで機能が大幅に改善されています。
ここでは全てを書ききれないので、また別の機会に紹介できればと（汗

最後に、「1.2」系のアプリケーションに「1.3」系のCakePHPに変更すると、とりあえずエラーが起きます（笑
まぁ当たり前な話ではありますが、特にクラス名が変更されている部分もあるそうなので、
変更を予定されている方は注意が必要かと思います。

これはテーブル情報をキャッシュすることで、フォームヘルパーなどでも利用される情報でもあり
大変便利な機能ではあります。
しかし気をつける点があり、「app/config/core.php」内の設定で「Configure::write(‘debug’, 0);」の設定を
1以上であれば、テーブルの情報を変更しても問題は無いのですが
0を指定(デバック無し)にしてテーブル情報を変更すると、変更したテーブルのフィールド情報が取得されない現象が起こります。
詳しい内容は割愛させていただきますが、まぁあたりまえな話でもあります。

しかし、ここで問題となるのが作成するアプリケーションの機能で、任意のタイミングにテーブル情報を変更するような
動的テーブルが存在するアプリケーション設計に問題が発生するかと思います。
その場合、キャッシュとして保存されたテーブル情報を一度削除をしなければ、変更された状態のテーブル情報を
取得することができなくなり、「find()」などでも問題となってしまいます。

そこで削除する方法を探してみました。
単純にCakePHPには定数の「CACHE」であるキャッシュディレクトリへのパスがあるので
その定数を使って削除する方法がありますが、無駄なコーディングが増えるので
CakePHPの内部を調べてテストしてみたところ発見！1行のコーディングで削除できます。

削除するためのコーディングはこちら

Cache::delete('ファイル名','_cake_model_')

ここで注意することは指定する「ファイル名」です。
この名称の指定はキャッシュ機能が「File」エンジンを利用して、設定を変更していない場合は
ファイル名のプレフィックスとして「cake_model_」が自動でつきます。
「ファイル名」の指定は、例えばデータベースへの接続が「default」でテーブル名が「users」の場合は
「ファイル名」を「default_users」となります。

これでテーブルが動的な設定でもCakePHPを問題なく利用できかと思います。

さてこの「paginate」（ページング機能）を少し解説していこうかと思います。
といっても自分のメモ的なものもありますが。。。

「paginate」（ページング機能）を利用する前に、CakePHPでまず必要な用意はありません（笑
前述したとおり1.2系では最初から利用できるので特別な用意をする必要がありません。
なぜ用意が必要がないかと言うと、必要なものはCakePHP側で先に用意してくれているからです。
例えば、「paginate」（ページング機能）を使うには通常はヘルパーの「Paginator」、ajax化を利用するなら
「ajax」ヘルパーが必要になりますが、CakePHPが各ヘルパーが無いと判断したら、自動で利用できるようになっています。
これは楽です（笑
ではデータベースから取得するにはコントローラーでどう記述するかとなると、
まずは基本は次のようになります。

$this->paginate();

すごく簡単な説明でした（笑
では条件を指定する場合、

$this->paginate($conditions);

またまた簡単です（笑
ここで躓きそうな悩み。。。
モデルを指定していないのに、なぜデータが取得できるか。
それは「paginate」が自動でモデルを内部で処理をし、データベースからデータを取得する
モデルを自動で設定してくれています。
ここでさらに疑問となるのが「Aコントローラー」の「Aモデル」の「paginate」ではなく
「Aコントローラー」から「Bモデル」の「paginate」のデータを取得する場合はどうするのか。

さすがにCakePHPは自動とはいきません（笑
そこで取得するデータのモデルを指定する場合は次のようになります。

$this->paginate('取得するモデル名');

ここで「？」と思う方、はい先ほどの説明でモデルを指定する第1引数には
条件指定を入れている場所でした。
実はCakePHPでは第1引数が文字列の場合は、それをモデル名として処理します。
では条件はどこに記述するのかですが、この場合は第2引数が条件指定の渡しとなります。

$this->paginate('取得するモデル名',$conditions);

これでモデルを指定したり、条件を指定したり自由に「paginate」（ページング機能）を使いこなせると思います。
ちなみに「$conditions」の指定方法は「find」と同じです。

このビヘイビアでは日本語入力を統一させるために
英数字とスペースを対象に半角または全角に自動で変換するためのビヘイビアです。
簡単な作りでもありますので、ビヘイビアの開発の参考になれば幸いです。

公開ページはこちらです。

CskePHPではDBに保存されているデータをツリー構造で取得することが可能です。
PHPコードを普通に記述するのは面倒な作業なのに、CakePHPでは基本1行で済んでしまいます（笑）

さて実際の記述は。。。

$this->モデル名->find('threaded');

たったこれだけです。簡単ですね（笑
ちなみにデータベース上にはどのデータが親なのかを「parent_id」で紐付けしておく必要があります。

上記のコードで？と思う方、お気づきでしょうか？
はい、通常の「find」の利用では「threaded」の部分には条件指定の配列を入れます。
このコードでは条件指定はできず、動作してくれませんorz

この問題を解消するには。。。
って複雑ではありませんし、実はCakePHPではちゃんと用意されています（汗

通常「find」の第2引数は「field」を指定するのですが、この指定を工夫します。
例えば条件を指定する場合は次のような形です。

$field['conditions']['AND']～

この「conditions」がCakePHPでは自動で、第1引数に置き換えてくれます。
これで条件指定があるTree（ツリー）構造も簡単にできますね（笑