After looking at an interesting Google group topic
Poll: what do you hate about CakePHP? i have tried to sum up the facts which people reasoned for hating/disliking CakePHP. Please be noted that all the facts listed here are based on users postings in the very topic and I have not tried to reproduce/test them all in a working environment. So, please take them home with your own consent. At least have a look at this topic and follow other links / facts behind the reason for such posting of users.
Here are the so called shortcomings of CakePHP:
- Poor PHP 4 support
- No namespaces
- No built-in Uploader( and image ) component
- Use of inflections/conventions in other languages (pt_BR).
- No HABTM counterCache
- Ignoring callbacks on associative queries
- The Ajax helper being tied into prototype/scriptalicious – for someone with a preference for jQuery.
- Lack of good userguides and tutorials. The ones that exist cover a few basics but thats about it, one struggles with more advanced stuff.
- Lack of a good, proper support forum.
- Inconsistency on model joining in queries
- Lack of bootstrap file for plugins would be another one (possibly even core.php and routes).
- MediaView still depends on the array of predefined MIME types (WTF?)
- Defining custom find types is unintuitive. It should be as simple as defining a function called _findCabbage() in your model to be able to use find(‘cabbage’).
- Habtm implementation:
Model::_deleteLinks($id). “Cascades model deletes through HABTM join keys.” I just found out reason why some records gets randomly deleted from habtm: cake ignores ‘condition’ filed in habtm assocciation definition. - saveall not recursive besides first level
- too complex ACL mangement
- broken IniAcl ( https://trac.cakephp.org/ticket/6103 )
- more configurability – eg. configure which controller subfolder a
particular controller/model is located in (currently has to search
through all folders in $controllerPaths bootstrap variable, takes
unnecessary time) - js, css minification/compression, packing, gzipping
- debugKit in core (or similiar)
- gzip
And many more..
At last but not least, i would quote one of the user saying on this very post:
I hate that it is a powerful framework that can make the tedious work of developing sites a breeze. Its strict adherence to the tried and true MVC model is a pain point as well. Why so logical?
I hate the active community involvement and powerful documentation and API sites. I hate that people expect Cake to do every little thing.
It is a framework! Not a solve everything-all-in-one-cms-portal-file-
manager-blog-forum.
Use the framework to create an upload component, it takes all of 5
minutes!!
I hope you enjoy this and that post!
I’ve used both quite a lot, and I find CakePHP to be a royal pain in the ass and CodeIgniter to be an absolute delight.
Totally Agree I hate CakePHP too
The MVC model is good but the code embedded in the ctp is against all separation presentation-procedure separation.
Best Regards, Paul
Nate, your attitude stinks. Take some constructive criticism like a man. Even if Baker was incorrect on some points there is no cause for such vitriol.
I stopped using cake because I need Try-Catch to work. I suppose you will insult me too.
Sorry, I’ve been sick for a few days.
I must be missing something here. I did a quick test to prove that you were right about the describe queries executing.
My assumption is that if I put:
CakeLog::write( ‘_ExecutingSQL’,$sql );
In the “_execute” function on your dbo collection of functions ( I refuse to call them classes since they are more of a collection of functions then a real class ).
I would expect that if debugLevel is set to 0, and caching is on, then I wouldn’t see these queries in the log.
I did two quick tests ( even though I’ve done this exact test at least 5 times before with the same exact results ): first tests with debugLevel = 3, caching enabled, the results were that the describe queries showed up in the logs. The second dest was using debugLevel=0, caching enabled, same results in the logs.
So, after testing this again from the stand point of trying to prove you right, I find that you are in fact wrong. Now, maybe it’s the case that we’ve done so much work to improve upon the dbo layer stuff by adding things like exception handling and speed improvements that we’ve inadvertently removed whatever it was that was caching the queries when debug is off. It’s entirely possible, however I’ve seen the same thing happen with the latest production release of the framework, so I’m doubting this as the culprit.
Always good to see the front runners of open source projects prove their eloquence with such literary masterpieces as “you’re full of shit.” Thank you for once again proving my point: just as childish and immature as the script kiddie playground you use. Statements like that make me thing that perhaps you should seek anger management sessions to get that anger issue under control. If someone like me can get you riled up that much by pointing out the painfully obvious flaws of your software, then perhaps you have more issues then just being brutally incompetent.
Thanks again for you’re continued participation in this black hole of a thread, I look forward to your next petulant rant of profanities.
Baker:
Oh, also, you’re full of shit.
“In the interview she admits to having to make significant changes to the framework to get it working properly in their environment. Based on that I’m pretty sure the firefox addon site isn’t using the stock CakePHP build.”
I went back to listen to the podcast again (which I was on). All that Laura mentions is having made “tweaks” to the framework, and all the specifics she mentions are all allowed by (or using) the public APIs, i.e. they don’t involve any hacks. If that weren’t enough, the AMO codebase is public (http://viewvc.svn.mozilla.org/vc/addons/branches/), so you can verify that they’re using a stock install.
Baker:
We have tests covering every aspect of the functionality. What am I gonna believe? That, or some random guy who thinks it’s broken? If it’s “broken” for you, then you set it up wrong.
Regardless, you should really quit while you’re behind. You sound dumb enough already, no reason to make it any worse.
Yeah, but if caching is broken, describes happen all the time, you should really review your core more closely.
Baker:
Also, with regard to “discussing these topics as potential bullet points for future releases”, you’ll note that I (the lead developer of CakePHP) was the one who started the thread, in order to solicit feedback from our users.
If you’re going to ask for peoples’ attention by contributing your thoughts to the discussion, at least do us all a favor and pay attention to the discussion itself.
Baker:
I don’t really have the time or inclination to directly respond to your rant, but suffice it to say that most of your complaints stem from your across-the-board lack of understanding of the subject matter.
Case-in-point: your complete obliviousness to the fact that the DESCRIBE queries which Cake runs are used for table introspection, and are only run at regular intervals in development/test mode; in production these values are cached, and switching an application to production mode is as easy as changing one setting in one configuration file.
This is completely obvious to anyone even remotely familiar with how CakePHP works, and your lack of even a basic knowledge of it is a clear demonstration that you’re simply speaking out of your own ignorance, and no one should pay any attention to anything you have to say about it.
Mr. Bryant ( I’m assuming male gender, please correct me if I’m wrong about that ):
The firefox addon site does indeed use cake, however, you may want to take a listen to the podcast interview of the lady who runs that project. In the interview she admits to having to make significant changes to the framework to get it working properly in their environment. Based on that I’m pretty sure the firefox addon site isn’t using the stock CakePHP build.
With regards to your WTF assertion, I was trying to point out that CakePHP does not take advantage of any kind of Object Oriented Programming techniques. Specifically flow control using try/catch/throw blocks, but to a lesser extent Access Control Level hooks on object variables and methods like private/protected/public.
Finally I’ll wrap this up with one final thought. It’s unfortunate that my comments are usually met with such angst and vitriol as displayed by Mr. Bryant. Instead of discussing these topics as potential bullet points for future releases, or digging deeper into the meaning of the message you instead attack my grammar. However, the most frighting ( and perhaps most illuminating of your skill set ) part about this is that you seem to lack any grasp of the very basics of Object Oriented Programming. I guess that’s just par for the course in the php community.
Way to represent Mr. Bryant, you have once again shown me that the php community and it’s members are still just as childish and rudimentary as the language itself.
Yeah, “Baker” I disagree. Firefox Addons uses CakePHP. I presume they have had more than 100 concurrent users. Perhaps I am missing what you meant but “Acl’s” on methods/object variables?
Not to mention with your terrible grammar the entire comment is damn near incomprehensible.
WTF does “* No usage of OOP in so much as using try/catch/throw’s or proper acl’s on methods/object variables.” mean? Try writing out your whine in a complete sentence next time.
In regards to the point above on “Poor PHP 4 Support”. I believe the complaint from most people is not the poor support for PHP 4, but rather the fact that there is support for PHP4. What people are looking for is a complete PHP 5 solution, to push forward to the future.
Cheers,
Graham
I find that the most annoying things about cake are the inner workings of cake, my short list would look something like:
* No usage of OOP in so much as using try/catch/throw’s or proper acl’s on methods/object variables.
* Cake in an enterprise grade context is nothing short of an epic fail. I blame this on a long list of things ranging from it’s use of output buffering to it’s woefully idiotic data interaction layer. ( read: doing a describe table on every table in a db per request )
* Caching at all levels is horribly inadequate.
* Cake forcing camel casing between model and view is completely unacceptable.
I couldn’t care less how great the forums are, or really anything else, the simple fact of the matter is that if it can’t handle more then 100 users using the site at the same time on a Dell 1850 ( go find the specs yourself ), it’s not good enough for me. And if your thinking that the problem is at the db/memcache level, I’ll tell you right now the loads were less then 5% on those machines while the web server ( apache or nginx ) was choking itself at 100% usage and an average of >30 second load times.
The reaction I generally get for pointing these things out is something along the lines of “well you shouldn’t be looking at the backend code anyway.” In my experience that’s something you hear from people who don’t want you to figure out how bad their code really is.