debuggable

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']);
  fclose($out);
  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 code.cakephp.org, 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 live.cakephp.org.

-- 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.