Behaviors
I just recently found out that the attach() and detach() methods I have always been using seem to be deprecated (or at least only available for BC) – and that one should probably use load() and unload() from now on.
That is sure something I will have to get used to.
Many new features in 2.2
It is worth reading the migration guide on this one. The logging has greatly improved, also the Error Handling, the CakeEmail lib and CakeTime (finally with timezone handling).
A very new feature just recently introduced is the validator object to better interact with the model’s validation rules.
I already started switching some of my apps to 2.2 – although it is still beta it doesnt mean one cannot use it.
It might not be recommended for high profile websites just now. But in most cases it will run at least as stable as 2.1. Only the new features might still be kind of buggy. But since you don’t use them yet you will be fine. But due to a great test case coverage there shouldn’t be too many surprises for your live apps -even if you start using some of the new features.
What I really am looking forward for in 3.0
Namespaces
Of course! Hopefully it will help to remove some of those many collisions we still have in 2.x with class names.
Better approach on aliasing
As outlined in this ticket aliasing as well as correctly merging is broken in the current 2.x version. I fixed it and applied it locally. Unfortunately, the devs are not willing to accept the change as useful fix. I also prosposed bootstrapped aliasing which would make most sense. If declared this early we can avoid conflicts in the controller level.
Better folder naming scheme
As outlined in my proposal @ http://cakephp.lighthouseapp.com they naming scheme for 2.x creates some conflicts – especially in the View folder.
Those should be resolved for 3.x.
Long overdue bug fixes
- Folder::merge (I applied that fix manually and locally)
- Containable recursion (also applied manually)
and some minor other ones
Indentation for method comments
Currently they are still not indented. But since the methods are indented (one tab), their comments should be, as well – so both are on the same level. I do that already on the user land site (just as most other php code out there) and hope this will be fixed in 3.0. It is annoying if you want to copy and paste methods from one to another. Lots of indentation correction is necessary.
PSR Framework Standards (or: what I am not so much looking forward for)
Cake2.x already tries to comply with the Psr-0 standard which is about filename conventions in a framework. And the Psr-1 standard is fine, too.
Recently, psr-1 and psr-2 have also been approved as standards. Although many of it reflects the way cake handles it and as it should be there are some major flaws. And I am glad that cake doesn’t follow them (yet).
For starters, the biggest mistake ever in this standard: using spaces for indentation instead of tabs. That’s just so awfully wrong and 19th century that I better don’t even go into any details here. It is sad that even some core developers who tried to reach those guys didn’t succeed in convincing them that they are making a huge mistake.
Secondly the way braces are set for classes and methods (in a new line instead of the same) which stands in contrast to the way it is done for conditional statements where it actually is on the same line. In the end an ugly inconsistency.
The (in my opinion wrong) PSR-1 standard states:
class Foo
{
public function class bar()
{
if ($var) {
// ...
}
}
}The correct bracing (which cake fortunately uses) is:
class Foo {
public function class bar() {
if ($var) {
// ...
}
}
}It not only reduces the vertical length (and therefore the readability especially for larger classes and methods) but also keeps the bracing consistent throughout the document.
But not all is bad. There are a few good approaches. And if all those frameworks grow together a little bit due to a common standard it will help the cross-compatibility in the long run.