First thoughts on CakePHP from a Rails perspective
I have a new project coming up that seems like a great fit for Ruby on Rails, particularly the RESTful interfaces that have gone in over the last year. However, the typical questions about using Rails apply here: I’m not sure how well the project’s hosting environment will support Rails, and collaborators aren’t as familiar with it. Thus, it seemed like it might be worth another look at options on the PHP side of things. I keep hearing that CakePHP is Rails-inspired and has many of the same advantages, so today I’ve taken the stable version (1.1.8.5850) for a spin, letting the Cake manual’s blog tutorial get me started. Here’s what I’ve noticed about CakePHP development as practiced in the tutorial — maybe there’s better ways to do things & the tutorial just isn’t mentioning them?
- No migrations; you have to generate the DDL on your own, both initially and for any subsequent modifications. Also, no model or controller generators. It’s definitely nicer to just do
script/generate scaffold post title:string body:text; rake db:migrateand be off to the races — from Rails 1.2 on, those races include the whole REST business. To be fair, there is a one off reference to ‘bake’ scripts in the CakePHP manual, but no pointers on what those are, or where they live, and the website isn’t much clearer. - No TDD. Woah. That’s, like, half the advantage of Rails — automated testing is right there in your face, and is firmly entrenched in the community.
- PHP code is not quite as elegant as Ruby. For example, generating a link to delete a post looks like this:
$html->link('Delete', "/posts/delete/{$post['Post'][id']}", null, 'Are you sure?' ). Can you spot the syntax error? Probably you can, but it took me a good few minutes. The Rails equivalent would be
link_to "Delete", { :action => "delete", :id => @post.id }, :confirm => "Are you sure?", :method => :delete - A lack of the experiences baked into Rails. For example, after the Google Web Accelerator fiasco, it became common practice to make all links to destructive actions happen via POST, which can be done via link_to’s :method parameter. Compare to the GET-powered delete link above, straight from the Cake tutorial.
- I miss my vim & rails integration, which makes creating and navigating the various files a breeze. (Glad I went to the trouble of making that a link, as it got me re-reading the plugin’s about page, and I saw the parts about partial extraction and migration inversion, neither of which I’d noticed before)
On the upside, using CakePHP sure beats writing a CRUD-heavy PHP application from scratch. One of my current projects, a completely custom contact management application, would be in much better shape if it were using CakePHP instead of the project-specific ORM I cobbled together — I’m going to have to give conversion of that project to CakePHP some serious thought.
But is CakePHP a DSL for the web in the sense that Rails is? Not yet.
December 15th, 2007 at 10:26 AM
This last year we actually went through a similar “what framework?” sort of activity for the redesign of ArtsConnectEd, and we’ve landed on Symfony. Worth a look if you get a chance, but the online tutorial (Askeet) is a bit deprecated at the moment… So it’s hard to take for as easy of a spin, but I believe the “first app” page is still mostly right.
I took a good look at CakePHP but without having a Rails background it didn’t appeal as a crossover framework. Symfony really seems to have better docs, a better community, and is using a lot of “best of breed” open source pieces all tied together into a nice framework.
Anyway, my latest nightmare has been the ORM plugin - Doctrine is going to be incredible, but it’s still beta and after almost a week of messing with it I still couldn’t get it to do inheritance the way I wanted, and Propel wasn’t using PDO. Finally there’s a (beta) version of Propel 1.3 which does use PDO and is waaaay faster thanks to it, so I’ve gone back to Propel. So far so good on the inheritance and many-to-many-to-many tables I’ve been forcing at it.
Hopefully I’ll get around to blogging all this at the Walker soon, but it’s been hard because I keep second guessing my decision!
December 15th, 2007 at 11:19 AM
Thanks for the insights. It will be interesting to see if any newcomers can catch up to Rails in the next 5 years. My intuition is that PHP and Perl have jumped the shark, while Ruby and Python are on the rise. Thus, I speculate that both of the problems that you cite for rails (lack of developer knowledge and lack of hosting support) will go away soon. I also speculate that if any platform rises up to overtake Rails, it will be based on Py, not PHP. Unsure, though. Maybe it will be Lisp on Rails!
I’ll be curious to hear more about your new project as it unfolds! Max
December 15th, 2007 at 3:49 PM
Nate — it’s interesting to hear about the ArtsConnectedEd redo process. I didn’t look at Symfony for this project mainly because the searching I did for Symfony & REST didn’t turn much up, while there were a few examples of using CakePHP to do things a bit more like Rails’ REST hotness. Looking forward to hearing more about how the ACE project works out.
Max — definitely agree with you on the language trends. It seems like most people (not all!) who give Ruby or Python an honest try don’t feel like going back to Perl or PHP; as a consequence, Rails and Django look like some of the more interesting web development communities. Though you can never completely discount Scheme on Skis.
Definitely agree that the Rails hosting situation is likely to keep getting better, as more and more people are using it & asking for it where they host.
January 23rd, 2008 at 9:25 PM
[…] advice from Nate, I’m taking Symfony for a spin (using the stable version 1, not the under-development 1.1), […]