CakePHP taking it apart, and the better written world of sinners..

I was asked a few months ago to look at Cake PHP as an option to develop a new project, rather than use the components that various members of the maintenance team actually knew (mostly PEAR packages). While there always significant benefits with sticking with what we knew, It was only fair to do a reasonable evaluation. It did not come of much better than those CMS's. Although the code quality is significantly better...(yeah commenting / documenting!)

Let's start pulling apart some of the problems. - This is just from browsing SVN trunk.

My base class is better than yours .... the Object class

Now there's a name asking to be caught by internals, (they probably won't, as namespaces are pending, but you never know). But this is a bit of a clanger.

$x = (object) $somearray;

$x = new Object();

Great way to confuse programmers who do not know PHP inside out...

PEAR has had the PEAR class as a bit of a albatross around it's neck for a while. It worked well with PHP4, as it had a few useful features, like exception faking (PEAR_Error etc.) and fake destructor's etc.. , but for the most part, newer classes in PEAR do not always require it as much as they used to. Often it's only loaded as needed if an error occurs.

But the overriding conclusion that most PEAR developers have come to is that a Base class is not really a great idea.... - And calling it Object sounds like a really bad idea... (Cake, Cake_Core or Milk might have been better) . but then going to use it as a base class is not really a step in the right direction. Let alone looking at it struggling to find a purpose in life....

Making Objects out of the built-in features - The 'Array, String' classes

You can't imagine the number of times someone has suggested an Array class and String class to the PEAR dev mailing list. It's been shot down due to the basic premise, this is just wrapping native features of PHP with mostly simple and dumb methods..

Even before PHP6 (the unicode version), PHP still features quite a few tools to work with unicode and multi byte character-sets, iconv and mbstring provide pretty much all you need and are far more comprehensive than something that you can put together in a small file. I should know this, I live and work in one of the few countries that use multi byte character sets..

If you really want a good laugh have a look at cake/conf/unicode/casefolding ... looks like someone missed mbstrtolower()..

Lost Classes...

ScaffoldView is a class hidden inside the scaffold class (it is in a file and directory that has no direct, simple relationship to the name of the class)

How would anyone know where to find ScaffoldView?, I can just see the irc chat.
"Where's that ScaffoldView Class"
- oh it's in cake/libs/controller/scaffold.php
-- wow that's obvious isn't it..

- Opps we're repeating a deadly sin there...

Making simple things complex ... Session, Cookie classes

yes, I think we all have had that idea at one point, it goes in the trash when you realize all you are doing is replacing one or two lines with a new API, and a whole lot of redundant code. Forcing maintainers, and users to learn and remember things they dont need to know...

$_SESSION[__CLASS__]['mysetting'] = ......

$_COOKIE['...'] or set_cookie(....);

Who's been reading the Patterns book to much... Model?

It's a nice name for what when you really get down to the meat of things, usually ends up being a object representation of a database table. While not a complete relationship, the benefit's of working this way significantly outweigh the downsides of creating abstract model objects for your project along side having a database mechanism.

That's why just using DataObject database wrapping model is far more efficient in terms of code and readability over abstract modeling (which funnily enough is called DataObjects.) - And I will not dig too deep into the fact that Cake's layer here is just yet another 'not invented here' redo....

PHP's good at some things, It sucks as a template engine (or install your virus here free)

Yes, although Richard quoted me as justification for his crazy idea that PHP makes a great template language, It doesn't It's a crap one. It's sooooooo easy to accidentally write code that can accidentally output unescaped data, and open up your site to so many types of hacking (like finding out what your admin password is!).

That is the whole purpose of Template engines. They should protect you from yourself by default (while allowing you to be explicit when you want to shoot yourself in the foot). Not the other way round. This is where PHP fails. It defaults to outputing raw data, and you have to be explicit if you are escaping! - It's ass backwards....

Thankfully the introduction of ExtJS and Ajax based interfaces have significantly reduced the need for template engines and HTML outputing in general. Although unfortuntaly without a few Security hacks ExtJs author's seem to like security holes just as much.

PHP as a template engine does not scale, If you have more that two or three templates in a project, then you want unescaped output to be easily spotted (so you can do security reviews quickly and frequently) rather than be a matter of sifting through craploads of HTML searching for accidental echos which are missing htmlspecialchars, or data that may have been slipped through your complex plan to escape it before it got there......

Anyone got a good project to nail next?