Contact Us

Cake 3 interview with Nate Abele

Posted on 22/7/09 by Felix Geisendörfer

Hey folks,

since there is still little public information about CakePHP 2.0 and especially the all-new 3.0, I decided to do a little interview with Nate Abele, lead developer of Cake 3.

Hi Nate. CakeFest is over, and now everybody is slowly catching up on the announcement of CakePHP 2.0 and Cake 3. Can you give me a high-level idea of what those two new version are all about?
Well, CakePHP 2.0 is basically an update of the existing 1.x codebase for PHP5 strict mode compliance. What this means is that, beyond the benefits of shedding some extra code and structure needed for PHP4 compatibility, upgrading to 2.0 will give your applications, on average, a 25% speed bump right out of the gate.
Cake 3.0, on the other hand, is pretty different from the existing core code in a few notable ways. Mainly, it's been re-written from the ground up for PHP 5.3.
Is CakePHP 2.0 going to be compatible with 1.x? We saw a big upgrade from 1.1 to 1.2, is the upgrade to 2.0 going to be an even bigger one?
Actually no, CakePHP 2.0 will be almost 100% API-compatible with the forthcoming CakePHP 1.3, and 1.3 is still API-compatible with 1.2, except for a few deprecated (but still working) methods.
Also, when migrating from 1.2 to 1.3/2.0, we have a small migration guide which will alert developers to the few changes as they update their code.
Awesome, so it's going to be pretty much a free performance boost for all current 1.2 apps?
Yes, exactly.
Ok, back to 3.0. Can you talk a little about the fundamental changes in both PHP as language as well as its impact on the new CakePHP core?
Well, for CakePHP, going from PHP4 compatibility straight to a 5.3-only version is a very big jump, not only because of 5.3's new features, but also because of the features that have been available in PHP5 that we're now able to take advantage of.
One of the biggest new features in PHP 5.3, that has really informed Cake's new architecture is namespaces. The new core is organized into "packages", each of which builds off of other packages.
This not only makes the core itself very modular (i.e. packages can be used in non-Cake applications), but it also makes the plugin architecture extremely simple and powerful. Plugins can now include just as much functionality as any class in an application, or in the core, and can even dynamically replace core class dependencies.
Another of 5.3's new features is closures. Closures are anonymous functions (i.e. functions assigned to a property or variable) that can inherit the context of the scope in which they're defined. This allows us to inject custom functionality directly into classes and methods, and with 3.0, we've leveraged this in an interesting way with the filters system.
In the new core, many object methods implement this filters system, and this allows you to attach custom behavior directly to method calls: modify parameters on the way in, and return values on the way out.
This is extremely powerful, because it makes functionality like caching or logging a snap, as these can be applied in a completely unobtrusive way, without the class in question needing to know anything about how to do those things.
One thing we often struggle with as developers is figuring out which class a piece of logic belongs in, or coupling classes too tightly because each "needs" to know something about how the other works.
With this system, we can keep classes cleanly separated, but still make them talk to each other even though each one doesn't know anything about the other.
Another great feature of the system is that the interface is standard, and all filters can be applied the same way, so if you know how to write filters for one core class, you know how to write filters for all of them.
Do you have a simple example to illustrate this?
As an example, let's say I wanted to see a log of all the queries executed against the database. In Cake 1.2, we have logic built into the database classes to keep a record of queries that get executed, and output them on demand.
However, the database classes are for interacting with databases; they shouldn't have to know anything about logging.
In Cake 3, I can simply do the following:
Connections::get('default')->applyFilter('_execute', function($self, $params, $chain) {
  $out = fopen('php://stderr');
  fwrite($out, $params['sql']);
  return $chain->next($self, $params, $chain);
In this example, I'm getting an instance of the database object from the Connections class (this is equivalent to calling ConnectionManager::getDataSource() in 1.2), and attaching a filter that intercepts the _execute() method.
Now, I could send the output to a proper logging class, but for now I just want to see the queries sent to the error log, just so I can quickly see what's going on.
This code will now be executed every time a query gets run against that database, and all queries will be logged as I expect.
So filters are always instance specific and do not apply to a class in general?
The example is just a small taste of the power of the filters system.
For instantiated classes, yes, you typically apply them on a case-by-case basis. However, as the framework is still in progress, we have anticipated the need to apply configuration to all classes of a certain type, so in the future this will likely be possible as well.
Additionally, one new utility class available in 3.0 core is the Collection class. This class acts similarly to an array, but has some extra goodies, like allowing you to call a method on all the object instances it contains, just by calling that method on the Collection instance itself.
So in that way, it would be possible to apply the same filter to many classes at once using that technique as well.
Since you are mentioning the Collection class, I heard the Model layer is actually going to see the biggest changes in 3.0. Can you elaborate a bit on your plans for that?
Yes, in many ways the Model will change; in many ways it won't. For example, records are still queried by making calls like $posts = Post::find("all");
This, and much of the rest of the basic Model-interaction syntax, should be immediately familiar to anyone working with Cake currently.
Under the hood, however, the Model layer is completely new. Models now interact with the underlying DataSource architecture through a constrained set of methods using query objects. Query objects are extremely useful, as they allow us to encapsulate much of the query-generation work that was previously spread throughout several different classes. In addition, since the query object works with the data layer to generate queries, and since the core query object can be replaced with custom, user-defined objects, users can easily modify and extend the SQL syntax that Cake supports.
Building off of the Collection class mentioned previously, model return results have also been improved with the introduction of objects, not only for returned records themselves, but also for record sets. The RecordSet object, which extends Collection, acts like an array in that you can iterate over it with foreach and friends, but it has some other notable advantages, like being able to lazy-fetch records as you ask for them.
This reflects a design decision that plays out in many areas of the framework, which is only possible with the new, more object-oriented architecture, which is being lazy.
Any loading or processing that needs to take place, doesn't take place until it actually has to. Referenced classes aren't loaded until they're used, routes aren't compiled until they're queried, database results aren't fetched until you're ready to do something with them.
Aside from the many other architectural improvements, this makes the new core exceedingly efficient.
With all returned records being objects, does this mean CakePHP is moving towards a full ActiveRecord implementation?
Practically speaking, yes, that's where we're at. With PHP 5.3's new Late Static Binding features, we can now properly reference static classes as mentioned above.
Ok. A personal goal of mine is to stop using relational databases for unstructured data in 2009. Is Cake 3 going to be #nosql friendly?
Definitely. With the simplified DataSource interface and looser schema requirements, modeling non-relational data becomes almost as easy. The new model system is also more flexible in how it allows you to define the relationships between models; and with custom query objects, you can implement custom flags and expressions that are specific to whatever data store you're working with.
Fantastic! When can we expect to get our hands on those new goodies? Do you have a general timeline for cake 3?
While the code is immediately available at, it's still hard to say when we'll see an official release; but expect to see lots of movement on it in the coming months.
With Cake 3 advancing in both features as well as server-side requirements, how does it compete with frameworks such as Ruby on Rails, Django, etc.?
Well, conveniently, migrating from PHP 5.2 to 5.3 is pretty quick and painless, as very little has changed in the way of existing features. As ever, PHP itself is the easiest to use and easiest to deploy to platform on the web, and provided a host that supports 5.3, it's a simple matter of dropping the files in the web root, just like always. Additionally, with the falling cost of virtualized computing and readily available server configurations with PHP ready to go out-of-the-box, deploying Cake applications, or any PHP application, has never been simpler.
Maintenance for PHP applications has always been equally simple, and in terms of performance, PHP is always at or near the top. With its shared-nothing architecture, you never have to worry about memory management, dead-locked threads, or infrastructure issues when scaling across multiple web servers.
Ok, thank you very much for the interesting interview Nate. If our readers have any questions, will you be available to answer them in the comments?
Sure thing, thanks for having me.

If you are still looking for more CakeFest information, Matt published his CakePHP Digest #18 - The CakeFest Edition post and the first videos are starting to show up at

-- Felix Geisendörfer aka the_undefined

Update: The Cake 3 codebase is still labeled as experimental by the cake project. Play around with it at your own risk, the roadmap is still subject to change.


You can skip to the end and add a comment.

Mark Boas said on Jul 22, 2009:

Sounding good! Look forward to it's release!

Lucian Lature  said on Jul 22, 2009:

Can't wait to taste Cake3!...must be f****** delicious

tomo  said on Jul 22, 2009:

Sounds great!
This will definetly be a great leap forward in the way php code is written throughout the world.

Jacob Friis Saxberg said on Jul 22, 2009:

My next project will be written in 3 I hope.
Thanks people!

Nate Klaiber said on Jul 22, 2009:

Wow, sounds like some awesome changes are on the way for Cake 3.0. I have always enjoyed Cake, but been frustrated by the 'we return an array from our model calls' - so I look forward to seeing the implementation of returning objects instead.

Big pat on the back to all working on this, I look forward to playing with it! Thanks to Nate for the insight.

Kjell said on Jul 22, 2009:

looking forward to see 2.0 soon.

Julien said on Jul 22, 2009:

Thanks for this post.
But the main reason why i use CakePHP is because it lets me code in PHP4 with a decent structure and automagic. because a lot of my clients only have PHP4. If i had the control to install PHP5.3 i would rather install Ruby or Rhino or Perl 6. It's cool to see that PHP will evolve, though. But it still has an inferior syntax, IMO.

Jose Lorenzo  said on Jul 22, 2009:

Will Cake3 support fetching associations like this?

$post = Post::find('first')
$comments = $post->comments

I would really love to have something like that

Felix Geisendörfer said on Jul 22, 2009:

Julien: If you still use PHP4 because of your clients you may want to consider firing the clients and re-evaluating your overall priorities : ).

If you think PHP has an inferior syntax and another language will make you more productive - by all means, follow your instincts! Personally I'm sticking with PHP because it is the most powerful language out-of-the-box, nothing else ships with a base library that comprehensive.

Neil Crookes said on Jul 22, 2009:

Awesome blog post Nate & Felix, really good stuff.

I've got tonnes of stuff on at the moment, but after reading this, having a dig around in Cake3 has moved well up my priority list.

This progress in terms of sophistication of coding concepts and the flexibility and performance boosts they will provide will be friggin' excellent for the framework, and I want to say a big thank you to everyone on the core team. Top job guys, I'm very grateful.

Steve said on Jul 23, 2009:

Great interview. I know these are just version numbers, but it seems like CakePHP 2.0 will come and go with the already emerging CakePHP 3.0. Although I'm looking forward to 2.0, the adoption of PHP 5.3 and the use of namespaces has got me pretty excited.

isaacraja  said on Jul 23, 2009:

The announcement and the sample controller code for Cake3 makes me curious to see Cake 3 soon.

It makes me to ignore cakephp2.0 :) (in the mind)

Julien said on Jul 23, 2009:

@Felix :
Thanks for your response. You're absolutely right. And I'd like to learn advanced PHP5 techniques and fire my clients, but i love them. So that's probably why i'm sticking with PHP4. Because sometimes, there is a server that is stuck with v4 but the job still must be done.

Sometimes i even have this big project that i have to accept or reject. But i dont have any precisions about the version of php that the server is using. That's ridiculous. But so is the freelance webmaster job. It's extreme adaptation. That's why im stuck in the past and nothing is evolving. People are still using IE6. Hosts are still using PHP4. Even if exciting new technologies arrives, it is not usable for common corporate websites with pointy haired boss.

Fear of change? Yes.

Nate Abele said on Jul 23, 2009:

Julien: I think the point is that if you're good enough at what you do, finding clients that aren't too cheap to pony up for good hardware is easy.

This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.