After pulling my head out, I found the issue in the dispatcher. Around line 359 or so (I hacked up my dispatcher with additional comments while debugging) in cake/Dispatcher.php, you will find the following:

$output = call_user_func_array(array(&$controller, $params['action']), empty($params['pass'])? null: $params['pass']);

The problem is, call_user_func_array requires the 2nd parameter to be an array. As you can see, cake is passing 'null' if we have no additional parameters to pass to the controller action. To fix, just change 'null' to 'array()':

$output = call_user_func_array(array(&$controller, $params['action']), empty($params['pass'])? array(): $params['pass']);

Now everything should be working again.

Note that this particular application is using a very early version of Cake 1.2. This problem might be fixed in later versions.

The first thing I failed to consider is that one single tool is not an end-all solution to all problems. A fair argument has been made about Zend Framework -- it's not quite a framework in the traditional sense of things. CakePHP is exactly that; a framework. That is the essence of half of the problems that I and my colleagues have experienced when it comes time to scale. CakePHP provides a well structured framework (note: when I said structured before, I was referring to architecture, not file system structure) to quickly develop applications. (Do I discredit myself by saying that it's very good at doing just that?) With CakePHP, you get an application that's ready to go out of the box -- not so much with Zend Framework. Zend Framework is largely a library, not a framework. This is, after all, why it's able to stay out of your way so easily -- it wasn't intended to be there in the first place.

CakePHP is exactly that; a framework

The second thing that put me back in perspective is an article I recently read about how Zend Framework is "winning the wrong war". (I apologize to the author, I can't find your post to link to.) That posting makes a very good point. It talks about how Zend Framework strives to gain the approval of Ruby on Rails folk, but it's going about it the wrong way. Zend Framework is riddled with extremely useful components, thorough testing, and great documentation (most of the time). The trouble is, most people just don't care about any of that. Like that posting describes, most Ruby on Rails folk love RoR because of the little time to market required to get a conceived idea online. I'll go ahead and admit: Time to market with CakePHP is much faster than Zend Framework.

CakePHP's "weakness" (as I would have earlier described it) of being simple and concrete is where Zend Framework's "strength" lies. Yes, with Zend Framework you can have an application online fairly quickly, but you don't get anything out of the box. It provides all of the components needed, and recommends a file structure, but doesn't require one. This allows you to pick and choose what you want Zend Framework to do for you. But this flexibility comes at the price of a learning curve, and at the price of extra bloat for those sites not in need of the hundreds of extra components that it provides.

To make up for my skewed perspective, I hope to write a few more posts in the coming days comparing and contrasting features of both frameworks. In the mean time, allow this follow up to serve as somewhat of a rebuttal

Before starting a project recently, I spent some time doing some research comparing CakePHP and Zend Framework for rapid development.  I noticed that of the few articles out there, not many of them where able to offer any advice on using either framework for a new project.  In most blogs, it seemed to come down to preference.  My goal today will be to steer you away from Cake.

This article is intended for those that are familiar with the concept of rapid application development, and the benefit of using a framework such as Zend or Cake.  If you want more information on why you would use such a framework, This article is outside of that scope.

It's worth mentioning that CakePHP and Zend Framework aren't the only popular open source rapid application frameworks out there.  I'm only focusing on these two frameworks because I have the most experience with them, and can offer useful insight into their strengths and weaknesses.  If you're interested in other frameworks, have a look at any of the following.

Other Popular Frameworks

• Symphony - Built in Doctrine ORM.
• Zym Framework - a fork of Zend Framework, developed in parallel.

Cake is Heavy

Staying out of your way is a very important for many aspects in life, including your application's third-party framework. You want something that provides functionality and structure, but allows you to fulfill your own needs in your own way.

Cake is no low-calorie meal

There's nothing lightweight about it. Cake tends to get in the way of your application by requiring your application to be built on top of (instead of along side of) itself. When cake is bootstrapped (configured), it will look for your application specific configuration files in a hard coded file location that it expects. Although you can predefine the defines (which is a whole-other reason to avoid using cake) it uses to determine paths, you'll never be able to completely seperate cake from your life without modifying cake itself.

Code and Feature Management

One of my cleints' websites is was written on top of one of the Cake 1.2 alpha releases from a few months ago.  (By the way, did no one tell the developers that in software engineering "alpha" release is not meant for the public?) I recently upgraded to 1.2 Release Candidate 4 and had a few problems.  This is to be expected when you're using any non-stable version of anything, but what I didn't expect was API changes. I don't mean additional features, I mean changing APIs.  Granted they were few and far in between, but they were still unexpected.

Hanging on to Old Times

The most annoying thing to me is that Cake uses PHP4 style objects. I feel safe in saying that any community software being developed today that believes hindering best practices in order to support an obsolete (in the loosest of terms) version of software is not very forward thinking.  No class members or functions have access modifier, and I don't remember seeing any type hinting whatsoever.

// This is Bad!

class Animal
{
    var $kingdom = 'Animal';

    function foobar()
    {
        //do something very private
     }
}

// This is GOOD!

class Animal
{
     private $_kingdom = 'Animal';

      private function foobar()
      {
          //do something private
      }
}

No Namespace Consideration

Cake uses very generic class names with no consideration for names pace collisions. By using cake, you're forcing yourself out of using generic class names in your own application (which is a better place for generic names to be!). Want to name a class `Controller`, `App`, or `Model`? Too bad -- cake has claimed those names for you!

Another horrible practice of Cake's is using global functions. Hsughughugh. I cannot begin to tell you how painful and fragile this is. All it takes to cure a few of the problems this creates is to wrap them in an abstract class! I don't know why they would rather have the function uses() in a global namespace instead of wrapping it in a class as `Cake::uses()`. Some (maybe most?) have been fixed in RC4 (you use `App::import()` instead of `uses()`), but they still allow the abuse by keeping the functions there.

Conclusion

If you are reading this article, you're probably at a crossroads between using CakePHP or using some other suite. I could go on and on about why I personally hate cake, but when it comes down to it, the decision is yours. Despite my gripes, Cake is still a good tool to get a simple website up and running quickly in a structured manner, without reinventing the wheel. Just make sure your website will never need to be scalable, and that its codebase will never grow beyond the small flexibility it offers. I'm personally experiencing this pain right now.

Great for mom & pop, but corporations shouldn't dare

That's how I once described my thoughts on using Joomla as a foundation for websites to a potential client. I think I'll go ahead and reuse that for this article.