I’ve never had a great love for PHP the Language. It seems like if someone wanted functionality into the core language, they just vomited it up inside the code base, submitted it, and it was accepted. They are trying to make this better in the core, but alas it’s still too easy to do dumb things. And let’s not get started on the security problems.

But PHP the Platform is much more interesting to me. You can deploy PHP applications in just about any cheap web host solution. Run it inside of Apache via mod_php or maybe under FastCGI — doesn’t matter. It really is a write-once, run anywhere language. And lots of big applications use it — WordPress, Joomla, osCommerce, etc. You may not like the Language, but since it is married to the Platform, the Language is here to say.

I’ve mucked with CakePHP a time or two. It’s an interesting project to say the least. It’s a web development framework a la Ruby on Rails or Django, but for PHP. It strictly enforces the MVC pattern, which leans itself to more maintainable code. But, unlike RoR or Django, the Views are not written in a whole new templating language, but in PHP itself, and it gives you the objects that have your data in it to display.

Another interesting thing about CakePHP is how it creates Models. In RoR or Django, you create fields in Model objects and then run a script and it creates the database for you. In CakePHP, you just name your model appropriately and, when CakePHP needs that Model, it does a DESCRIBE on the table and populates the data points accordingly. This is good and bad — it means your database is the king. It also means that you have to follow strict set of conventions or configure everything in your Model object as to what is what. This means that you could use CakePHP with any database structure — in theory.  More on conventions later.

Anyway, CakePHP has been in the back of my mind for a year or so (at least) when I got approached with an opportunity to do a POC of a simple CRUD application. The POC would be hosted on a cheapo shared hosting provider, so anything like Django or Rails was out. So I dug out CakePHP and finished the POC. When it was over, the customer liked it and we really discovered what he was after — and it wasn’t just a simple CRUD application anymore! When we were specing it out and decided that the customer needed to get some high-quality, dedicated hosting, I asked if we wanted to write the real thing in Django or RoR. It was decided no for the simple thing that PHP developers are much easier to find. If I was unavailable and fixes were needed, they could easily find a PHP developer to do it. Not necessarily so with Django and with RoR (though I think there are more RoR developers than Django, but there are still more PHP people out there!).

So I put CakePHP through some tests and am still using it. Is it my favorite? No — that’s still Django. But it’s very livable, especially under the constraints I was in.  And, hey, it’s making PHP relatively painless to code in, and it’s not even making me feel dirty.

One thing nice about CakePHP is their console application, although they don’t tell you about that until you are on page, like, 100 of their docs. There is no mention of it in their tutorial! Blech!  It’s pretty easy though:

cake bake <name>

which will bring up a menu and you choose Model, View, or Controller.  You can also do:

cake bake model <name>
cake bake view <name>
cake bake controller <name>

More information here.

One thing about CakePHP that bugs me (and, actually, it bugs me about RoR, too) is that the naming conventions aren’t conventions I would use.   I finally  found this page which explains all the conventions in on place.  Also notice that it’s on the last page of their documentation.

This seems sort of a mixed review, but it’s not.  If you are working on a PHP application from scratch, it would behove you to at least look at CakePHP.  I like it — for PHP.  Would I rather be doing Django? Yes — but I can’t always be able to do that.  It’s good to have a framework on a ubiquitous, yet annoying,  language.