That is just one (possibly outdated) way to “force” joins in cake. There is a multitude of other ways to handle it. Linkable behavior works wonders… Another, easier option is outlined here: http://bakery.cakephp.org/articles/view/quick-tip-doing-ad-hoc-joins-in-model-find

… and there are DB migrations in cake as well, which are quite nicely done. Not to mention the excellent console tools.

P.S. Granted this post is a bit old, and cake has matured quite a bit even over such a short period of time, but I figured it’d be nice to share more info for any of your readers. (Yes, I am biased towards cake) :)

Also ran in to some issues with the convention/humanization of variable names (ie Person/people table). I had a species table. Since it’s spelled the same in plural and singular I had stuff in generated code like foreach($species as $species) {}, which popped out in every place where I used that model, so I defined and exception for the humanizer, yada yada yada but in the end I had to say screw it and refactored everything into ‘subjects’ which depleted my happythoughtmeter.

I mean, sure, it’s generated code. Sure, it’s cake 1.2x (which never seems to get out of RC) but well. The alternative would be to use 1.1 which is stable but has stuff like ‘you’re limited to one validator per model.’

More than a rant (although this is a rant) this is intended as mini-cautionary tale. Frameworks all look fantastic from their websites’ testimonials and feature list. However since one will be basically marrying whichever one choses I think it’s important to know the crap as well as the goods.

That said, I’m sure I’ll eventually find some gotchas with symfony as well but so far other than the slightly steeper learning curve I haven’t really found anything serious to complain about.

As my app grew from a couple tables I started to run into limitations of cake’s ORM. There’s for example, no sane way of specifying joins. Turns out joins are only performed on hasOne and backwards on belongsTo relationships. You can’t tell it, I need a join here. You have to rely on the ORM’s magic to make that decision.

There’s also that you can’t easily paginate multiple models in a single page. Example: Author hasMany Comments, Author hasMany Article. Viewing the Author page one should be able to see Related Comments and Related Articles. In fact that’s how the baked forms and scaffolding show this data. Paginating those 2 is a different story since by default the parameters that specify the page you’re in do not distinguish which model you need to paginate. For what should be a nice condensed view you have now to have separate pages.

There are tricks like this http://teknoid.wordpress.com/2008/07/17/forcing-an-sql-join-in-cakephp/ which I personally find ugly. For pagination I understand you can have multiple paginators per page with ajax but from what I’ve seen the whole system asumes you’ll be paginating one thing at a time so it’s more of a workaround than anything else.

For me the point of using a framework is to keep code clean and me happy. These and other things have the opposite effect. As much as I dislike symfony’s verbose style and its multitude of config files it turns out they made the right choice (for me) by chosing to use well established ORMs instead of taking on the task of reinventing the wheel.

I really liked cake. I just wish it didn’t suck at the things I need to do like queries and pagination… :(

I don’t understand three quarters of what you’ve written here, but I am so very grateful for what you do. For those of us struggling to understand as many aspects of web development in relation to NPO’s as we can, I wanted to say thank you and please keep it up.

tjs

I went through a similar exercise in January (http://slagwerks.com/blog/index.php/2008/01/23/puttering-around-with-symfony/) and noticed a few major benefits of symfony over cake:

- the database integration is a huge timesaver
- symfony makes it easy to write tests for your app