I ran across an article comparing CakePHP and Symfony and found that the writer had a number of preconceived ideas about CakePHP. These same ideas keep popping up everywhere, used by people looking to get their hate on about CakePHP. I sent a very well-reasoned email to the writer clearing up some of those misconceptions, and (to his credit) he replied to me saying:
"Thanks for a brilliant email reply to my blog post about CakePHP and
symfony - and taking the time out to send it. Thanks so much for the
pointers and corrections."
So, in the interest of clarifying things about CakePHP I thought I would share that email, slightly rewritten for this blog posting, but the content is roughly the same.
Lack of Documentation
Man, this one will just not die. One complaint seems to be the lack of documentation similar to what Symfony has. I think that's totally fair in that there are very few *detailed* books out there explaining how to use Cake. However, I feel that there is more than enough information on people's blogs on how to build things using CakePHP. So, perhaps it requires time to search around via Google or your other favourite search engine, so I can understand how people are unable to find one unified source for this info. I don't think you could ever have one definitive source for info about Cake, and the majority of contributors to Cake blog about it. If I had to pick what I would call the definitive source out of the crowd, it would be the CakePHP Cookbook.
Scaffolding
While I think scaffolding is a great idea to show off the strength of CakePHP, it is a toy and I have never used the scaffolding to build anything other than a throw-away prototype. I use 'cake bake' to generate the "scaffolding" for my application and then edit those files. In fact, I'd say that 'cake bake' is the essential tool that anyone who uses CakePHP needs to start using RIGHT NOW if they are not already.
It is my personal opinion that showing people the scaffolding stuff that Cake uses by default is counter-productive and a waste of time. It just confuses them and leads to frustration, which is clearly what has happened to you here. So if you want to use CakePHP, just don't use the scaffolding at all.
Models are tied to controllers in a 1:1 relationship
Nothing could be further from the truth. Here's a sample of some code from a project I was working on that shows this
-
class CalendarController extends AppController {
-
var $name = 'Calendar';
-
-
function admin_index() {
-
$results = $this->UserClient->Location->findByLocationId($this->Auth->user('location_id'));
-
$cases = $this->LegalCase->groupByDepositionType();
-
-
$this->set('pending_depositions', $pending_depositions);
-
$this->set('cases', $cases);
-
}
For those keeping score at home, that's one controller interacting with 4 different models. You can have controllers that don't have any associated models. You can also have controllers that don't talk to any model at all by default by setting the uses array to equal null. So the idea of Cake only being for simple "one table = one view" is simply wrong. Again, I'd like to find a way to get rid of this idea that you can only have one model per controller.
Cake's Ajax and Javascript helpers do not support graceful degradation
I don't use the Ajax helper but a quick look at the online documentation shows that this myth might actually be true. Core contributor Mark Story has a post showing you an examplehow to make that happen in CakePHP, but it requires a little bit of work. Maybe Symfony is the only "mainstream" framework out there that has put effort into implementing that. Personally, I don't use the Ajax helpers in Cake as I prefer to use jQuery.
Cake's HTML and Form helpers produces bad markup
I don't feel that's true at all. The form helper can produce legends and fieldsets...and those can be turned off via parameters in the calls to that particular helper. Again, more work needs to be done to clue people in about this stuff. The online documentation does show what all the parameters that the helpers take do, so check them out to find out exactly how to bend if to your will.
Unit tests are an afterthought
Definitely not true. When you use the 'cake bake' utility to create the outlines of models and controllers it also creates the empty unit tests that go along with it as well. Cake also has a very extensive set of unit tests for the framework itself and code coverage that is up past 85% last that I had seen. Testing is important, and it's good to see that Symfony also has a commitment to that.
CakePHP is not an "enterprise capable framework"
Could someone please tell me what this actually means? Cake is used by Mozilla for their Add-ons site, so I think that's about as enterprisy a use as you're going to see out there.
So, a few myths about CakePHP busted I hope. The thing I wish to emphasize to those who are looking at Cake to make sure they look at the CakePHP Cookbook and the online API documentation in order to fully understand how to use the various helpers.
Tags: CakePHP, mythbusters


i've come over to cake recently due in part to the political bloodbath happening in the symfony world and I have to disagree with you about the documentation. The biggest problem with the cake book is it leaves a lot out, and when it does cover stuff, it only covers very few iterations. it doesn't address cake concepts well at all. and as you know getting the concept is more important than the details most times.
In addition there are reams of undocumented classes, or poorly. you can read the symfony api and get how to use things. Cake has a lot more internal data transformations and conventions that are unclear where they come from.
lastly, there just aren't that many cake bloggers out there. I've started one, trying to add to the content, but i keep finding myself having to explore cake internals to solve problems and that was pretty rare for me in symfony (though it did happen).
more than anything my experience of cake is that symfony has gone too far down the road of oop and cake not enough. arrays are great.. but you can't extend an array class when you want to easily manipulate results
@ruzz
I'm curious as to what kind of problems you ran in to that you had to explore Cake internals to figure out, because this is something I seem to hear from other people as well. I can count on one hand the number of times in 2+ years I've had to do this in order to figure something out.
But you did raise a good point about how the Cake cookbook does not address Cake concepts in a detailed way. Unfortunately, it cannot do that as it has to be broad in the material that it covers. I think this idea that people feel they need to dig into Cake internals to figure something out comes from perhaps a lack of understanding of how Cake does things.
The documentation has certainly come a long way and with a 1.2 final release, it'd be nice to see a definite push to bring the documentation up to match. There are still things undocumented and while I've tried to document things in the Book when I can, I don't always have time. I still have to poke around in the core to figure things out.
But I still enjoy the framework and it still saves me time in getting stuff done. Chris, good work on clarifying things. I followed the Symfony advent calendar and I still feel it's too verbose.
i agree that the cookbook is a bit inconsistent. some parts are in-depth, other parts are quite bare. advanced routing, for example. after a bit of rifling about in it when it came out, i gave up and went back to the api documentation, which is pretty good. not the most in-depth api docs i've seen, but adequate for any developer who has his/her head on straight to figure things out.
as far as enterprise, yeah, wtf does that mean exactly? that it's capable of running an application for an enterprise? your nod to mozilla add-ons cinches that. does it mean that it's scalable? *anything* is scalable, if you know how to do it and/or have enough time and money. i've found cake to be quite scalable, 1.2 uses little memory in comparison to previous iterations and to other frameworks. i've managed to "bend it to my will" in that, without hacking the core in any way, i have an entire EAV schema serving up reams of information, all managed via an ExtJS backend, fed completely by JSON and generated JS. i'd call that "enterprise" any day.
Chris, thank you for posting this.
My comment on unit testing was just about the fact that in symfony it's right up there as a mainstream feature. It wasn't a criticism of Cake, but more of a 'oh, wow' moment when looking at symmfony.
My comment about enterprise ready was more to do with symfony bearing a resemblence to Struts - I could easily visualise a large organisation using symfony. It's structured well, so groups of people can work on one application without treading on each other's work. It's also simple to pick up an existing application and work on it because it's structure seems very logical and straightforward.
I didn't get that impression with Cake - and from your post above - a lot of that is down to not fully understanding the framework itself. Thank you for highlighting what I've got wrong - that helps me better appreciate the capabilities of Cake.
Mike.
You posted this code:
class CalendarController extends AppController {
var $name = 'Calendar';
var $uses = array('UserClient', 'CalendarPending', 'LegalCase');
function admin_index() {
$this->UserClient->Location->contain();
$results = $this->UserClient->Location->findByLocationId($this->Auth->user('location_id'));
$this->CalendarPending->contain('LegalCase');
$pending_depositions = $this->CalendarPending->find('all', array('conditions' => array('location' => $results['Location']['name'])));
$cases = $this->LegalCase->groupByDepositionType();
$this->set('pending_depositions', $pending_depositions);
$this->set('cases', $cases);
}
There are some things that semantically just don't make sense..
like
$this->UserClient->Location->contain();
What is this code supposed to do? Contain what?
And few lines below, the same:
$this->CalendarPending->contain('LegalCase');
I don't even like the coding standards (seems pascal case with some difference)
It uses PHP4, with all its design mistakes.
In symfony you'll never see something like
$this->set('cases', $cases);
I mean, it's the kind of syntactic sugar that make you trust more the tool you're using.
Enterprise ready may mean even this, when you look at the symfony code, you can understand what's happening. And for enterprises this is very important.
With Cake, and other frameworks, IMHO this is not true..
@lloyd27
The code was supposed to illustrate how you make a controller talk to multiple models. Perhaps a bad choice of coding sample. I will edit it to show a better example.
@lloyd27
You also raised a point that people seem to complain about as well. Yes, CakePHP uses PHP4 standards for naming class variables and methods, and in the core itself but it RUNS JUST FINE ON PHP5. The code sample above was for a project that had to run on PHP 4. You can use PHP5-specific functionality just fine in the code you write yourself.
CakePHP == PHP4 is a piece of FUD that is just ignorant and any developer who has used both PHP4 and PHP5 should know that.
Hey Chris, I think a lot of people are with you on just using jQuery for degradable Ajax (or any JS interactivity whatsoever). However, I think the helpers do make a reasonable effort (combined with the RequestHandler) to support graceful degradation. Some of the main use cases supported are things like links or forms which update a particular region of the page. The RequestHandler and Ajax helper work together to make it easy to re-use views, elements, and portions of views to serve up only a section of a page, or fall back to doing a full page-refresh when necessary.
Is there some other type or level of degradable Ajax that isn't covered? (For example, we still don't support the back button, so there's that).
@nate
Yeah, I wasn't sure what was going on with the Ajax helper, thanks for pointing that out. So that's another CakePHP myth busted.
There's been a lot of Cake hate recently and I'm quite confused by all of it. I've been using Cake since 1.0 and it's quite a wonderful framework. I'd hate to see the opinions of a few bloggers ruin the reputation of a fine piece of work simply because they don't fully understand the code. Trying to compare Symfony to Cake is like trying to compare Java to PHP - they're just not the same, so you have to have a different mindset when you jump into it. (No, I'm not indirectly comparing Symfony to Java, so please don't be that guy).
One of the things I've noticed reading through some of the Cake hate is that Cake is so ridiculously simple that it confuses people who are looking for things to be a bit more complex. When it comes time to build code, people search for ways to do things with 10 lines of code that with cake would take 1 line of code. It happened to me a couple times when I was first working to learn Cake, and proceeded to smack myself up the head after realizing how deceptively simple it was (Set class anyone?).
About Cake having a bad rep for being backwards-compatible with PHP4. I'm so tired of this argument. Good gravy, the Cake team took a considerable amount of time to write code for php4, which makes the framework backwards-compatible. If you dig into the code, you'll find there are actual PHP5-only functions that have been implemented in Cake for this very purpose. You get the functionality of PHP5 (minus a few code constructs), but you don't HAVE to write your app in PHP4. In fact, I'd say it is 110% better to build your Cake app for PHP5, but it's REALLY nice to have PHP4 compatibility available for those clients who want to keep their current servers and are unable to upgrade to version 5.
[...] around the CakePHP framework (as presented most recently by a different blogger) Chris Hartjes has made a new “mythbuster” post to his blog today with a rebuttal to the points from the other article. I ran across an article [...]
To be honest, I think the main problem is that people don't take CakePHP developers very seriously. I remember when you where using eval() in the session component. How can you trust a developer or a framework after something like this?
@alan
Call me an optimist, but isn't what really matters what the core code looks and behaves like *now* instead of what it used to be? If the code is still there, then you definitely have a valid point.
[...] around the CakePHP framework (as presented most recently by a different blogger) Chris Hartjes has made a new “mythbuster” post to his blog today with a rebuttal to the points from the other article. I ran across an article [...]
Alan, that's almost as bad as blaming Tim and Felix (http://debuggable.com/) for the atrocities of WWII.
That code hasn't been there for *years*. I didn't write that code, but I did write the features to replace it, and I'm currently the lead developer of the project. Therefore, by your logic, you should trust me (and by extension, the framework and it's *current* code) that much more.
@Chris
You missed my point. I don't know if the code is better or worse now. The only thing I know is that trust is very difficult to gain back. Specially if you are a programmer.
@alan
No, I understood your point. I just don't consider it such a big deal on how the way something USED to be. I'm more interested in the way it is NOW. Different philosophy, that's all. I have a different opinion of Cake because I know many of the people who have contributed code and I trust their skills.
I have it on good evidence that the Symfony and CodeIgniter core devs used to use eval() as reckless teenagers. As a result, I don't trust anything they code.
Chris, as usual...great post....I'm tired of all the fighting...Can't we all just get along?
Hehe... good comment Jonathan, made me chuckle.
Fact: Cake Hate is a product of ignorance.
The thousands of bakers that love the framework, use it day in day out, save oodles of time developing apps rapidly with it, can't all be wrong.
Can everybody stop comparing frameworks until you've developed at least several decent apps with them and got to know them pretty well. Any comparisons made with less knowledge than this are not worth the pixels they're p*ssing on..
Yeah it's weighty, but it's not weighty for the sake of it guys, come on. The cake devs aren't stupid, they don't bootstrap redundant classes for sh*ts and giggles. Its a full stack framework. And an incredibly powerful one at that. There's a hell of a lot stuff in there that will make your life a lot easier - just give it a chance.
Although Cake team are making great job (I'm a CakePHP fan) but there still some problems:
1- manual is very good, but some chapters need more stuff
2- ACL chapter is very messy, and many people are complaining about it
3- Cake's site needs more attention, like updating the homepage (put some other sites that use cake, put some showcases, some screenshots, some nice introduction)
and some other good stuff to make the first comers happy!
[...] around the CakePHP framework (as presented most recently by a different blogger) Chris Hartjes has made a new “mythbuster” post to his blog today with a rebuttal to the points from the other [...]
[...] around the CakePHP framework (as presented most recently by a different blogger) Chris Hartjes has made a new “mythbuster” post to his blog today with a rebuttal to the points from the other [...]
"Not enterprise ready" - Who said that?
The company I work for has been using cake since 1.0 and so far we have developed plenty of high(ish) traffic websites and have had no complaints related to performance whatsoever (except server issues of course). If your going to be that anal about performance, in fact, so much so that even Mozilla add-ons performance isn't good enough then you shouldn't be using a framework.
Another thing to consider is with the amount of time you save and assuming your time is money then you can afford to beef up the hardware it's running on.
In terms of documentation the best place for examples is here:
http://api.cakephp.org/tests/classes.html
CakePHP has some more weaknesses. Read it here http://www.slideshare.net/pcdinh/how-to-learn-to-build-your-own-php-framework-presentation (there are some pages which mention CakePHP architecture's shortcomings
Can you defend it?
Davidion
Chris, great article...however, I was some what confused by your comments about Scaffolding. Can you clarify a little more? If I understand you correctly, use cake bake and modify what it puts out, but don't use the scaffolding pieces for show and tell? Thanks.
@Rob
There is a difference between scaffolding and what 'cake bake' produces. I had a few drinks last night with one of my blog readers who lives in Milton (hi Colin) and we discussed the importance of nomenclature for a project, so perhaps all we need are some new terms.
Scaffolding is this feature that is built into Cake that will auto generate HTML *output* for you, not the files themselves. You can read about it at http://book.cakephp.org/view/105/Scaffolding. Again, I feel that it's just a toy that you shouldn't use for any kind of serious work.
'cake bake', on the other head, generates the actual files for you. I use 'cake bake' all the time, but NEVER use the built-in scaffolding.
Hope that clears it up for ya.
@Davidion
Defend? Nah, I'm not really going to play that game.
That presentation is focusing on CakePHP 1.1, which I do not use. Much of what he is complaining about is simply no longer valid in CakePHP 1.2, so I suggest that he go back and take a look.
No framework is perfect, so I don't understand the point of his presentation. If anything it is simply promoting his own framework that he thinks is better than anything else. His comments on dependency injection are interesting though.
I think CakePHP should appoint a PRO, setup an HR department and appoint a board of directors who do nothing - that will make it enterprise ready
I gotta say ... this is all very interesting to me, because I'm a recent cakephp convert.
I have been doing a lot of Ruby on Rails programming and loving it to pieces, but every now and then a project will come along that, for some reason or another, has to be done in php. I finally settled on cake after looking at Code Igniter, Zend and Symphony. It just requires the least change of mindset from Rails and it just seems more complete as a framework.
I have to say it has been fun and I can't understand half of the things that people complain about cake for, with the exception of Documentation. Its not bad, but the infuriating thing about cake is the lack of detail in certain critical places that leaves you looking at the API docs to figure out how the arguments in certain method calls work.
Apart from that and its apparent slowness (I was using RC2 ... haven't done much with it since then) I really think its pretty spectacular ... especially being a PHP product (which tend to emphasize get-it-done over elegance and quality code).
And there aren't that many books on cake either. I have the "Beginning CakePHP" by David Golding and I like it because it filled in some gaps in my cake jujitsu ... but I'm badly wanting a "The Rails Way" equivalent ... a painstakingly complete guide to cake.
Spot on, Chris! If I had the time to blog then would contain most of these. It's nice to see Jonathan, Nate, and the rest of the guys standing up for what they believe in. Now if only I had time to write that book for the rest of us... And I just want you guys to know that I want to write one real bad. I'm just afraid that I might just finish it *after* the next version of CakePHP... Cheers to the community that keeps our bakers alive, keep rockin'!
[...] Chris Hartjes has a nice post refuting pretty much everything said in this post comparing CakePHP and symfony. Kudos to Chris for his post, but mostly for actually getting through the original comparison. I started to read it to see what quippy little jokes I could make, but slipped into a 20 year coma after 3 lines. Fortunately WordPress version 47.3 has a cool feature where you can back publish posts and they will actually appear back in time, which is why you are able to read this. [...]