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.

Story time:

Thursday, July 2nd 2009. Officials announce the death of XHTML2. Multiple suspects, including HTML4, HTML5 and XHTML1 have been taken into pre-trial custody.

The investigation is difficult. XHTML1 seems to have no motive as XHTML2 was his son. The father can barely speak about his loss without bursting into tears. However, he is a very strict man and everybody knew he had extremely high expectations in his son. Could his bad temper have killed XHTML2 for making a simple mistake?

HTML4 however has a motive. He was once the big star in town. But then came XHTML1 and took that fame away. Every theater, including "the Fire Fox", "the Opera" and "the Web Kit" loved XHTML1 and told HTML4 it is time to retire. Not only that, many critics also saw great talent in his son XHTML2 who was competing with HTML5. So did HTML4 kill XHTML2 out of revenge, to free the way for his own son?

The prime suspect of course is HTML5. He was a direct competitor to XHTML2. The two had very different professional opinions. XHTML2, just like his father, was a strict perfectionist. HTML5 however is often characterized as a forgiving, practical performer. But investigators have found that HTML5 had the support of many cutting-edge theaters since at least 2004 and had no reason to fear XHTML2's competition. Did HTML5 feel he had to kill XHTML2 to simply destroy his strict philosophy?

3 years later. Investigations on the XHTML2 case have long been closed. XHTML2's death was classified as suicide. The media said XHTML2 could not gain the support of any major theater and killed himself out of desperation.

Now a new case is erupting the news landscape. HTML5 had a step brother, XHTML5, and his body was just found in a motel room. He was the new leader and last hope of a movement called "the semantic web". Probable cause of death - microformat overdose.

XHTML5's death marks the end of the movement. He and his followers thought they could make performance art accessible to a new audience of robots and intelligent machines. Those machines were very hungry for information, but could not understand performers like HTML4 and HTML5. "The semantic web" thought that by enforcing the strictness invented by XHTML1 and through the heavy injection of microformats they could perform at a level of perfection that could bridge the gap between the visuals and the underlaying information.

From early on, the "semantic web movement" was very violent. Non-supporters were labeled as reactionists. The standards developed by the movement made them totally blind for reality. The biggest theater, known for its greedy operators and huge audience, "the Internet Explorer" simply ignored the movement.

But then came JSON, a theater janitor who would permanently transform the stage. JSON himself was raised by JavaScript, a class of machines invented at the old "Netscape" theater. The JavaScript machines were originally only used to do basic lighting and other low-level work at the theaters and nobody really understood their true power. But through JSON they were able to communicate with other machines. Machines who previously only talked to XHTML1's grandfather - XML.

JSON just happened to be much more eloquent than XML, and his slang became quickly popular among a new generation of machines. And he became friends with HTML4 and HTML5. They could not understand each other directly, but the JavaScript machines were able to express JSONs thoughts to HTML4 & 5. So HTML4 & 5 realized that JSON could take over XML's job as a playwright.

And so the stage was slowly transformed. Plays were written by JSON who then performed them for the machines. JavaScript and other machines enabled HTML4 & 5 to perform the plays in their unique ways that were still more attractive to humans.

The XHTML family died because it wanted to write and perform for humans and machines alike. But the machines were not ready for it yet and wanted their own performances. Accepting this truth ultimately helped the humans who could now enjoy more entertainment & knowledge than ever, thanks to their automated friends.

=== The End ===

If you did not like the performance, entrance fees are unfortunately non-refundable. But feel free to release your grief over the death of XHTML in the comments.

-- Felix Geisendörfer aka the_undefined

We removed our old two-guys-in-a-garage theme and replaced it with the beautiful work of Abhay Singh. We could have kept the old look, but then we would have also had to buy a garage at some point.

We are now also offering commercial support for CakePHP, jQuery and Git.

Let us know what you think. That is other than that we should post more. We got a few goodies queued up already ; ).

-- Felix Geisendörfer aka the_undefined

PS: Be careful with our RSS bug, he does not like to be annoyed.

Hey folks,

if you are on twitter, you probably heard that cakefest #3 was beyond awesome again this time around.

Amongst other things, Nate spoke about the announcement of Cake3 which is a largely rewritten version of CakePHP that works exclusively with PHP5.3+ and takes advantage of all the new features like namespaces and closures. You can already check the source, but hold your breath - this version is many many months away from a release.

On the first day, Gwoo talked about the more immediate future of CakePHP. CakePHP 2.0 will pretty much be CakePHP 1.2 (ok, actually 1.3) with PHP5 strict-mode compliance. There should be no breaks in backwards computability, but we expect to see a significant performance boost from dropping PHP4 support.

There was a lot of discussion up front on whether Cake3 should be based on the current core or whether it should be a rewrite like it is now. We hope that the benefits of a new architecture will outweigh the problems of backwards compatibility in the long run. It will certainly be interesting to see the uptake of 5.3 as it is a much more significant revision than the version number would indicate.

Anyway, back to the past. The conference was preceded by a 2-day workshop. There was some trouble getting started since we intended to hand out a copy of the app we were going to build that had just the design with it, but falling back to an empty core worked as well. Over the 2 days Nate & Mariano did a fantastic job building a twitter-clone from scratch that also interacts with the actual twitter via a datasource and demonstrates many other CakePHP tools. I think we hit an even better compromise of not overloading beginners and making it still attractive to intermediates, but there also seemed to be some demand for an advanced-CakePHP only workshop.

The conference itself was quite fantastic as well. We had ~70 people at the event, which was a bit of a challenge when trying to pick bars & restaurants at night : ). Pretty much all presentations were fantastic and seemed to be a good mix of different topics.

Garrett also introduced us to a new gentleman game that he has helped to develop named: Fork Master. The game is beyond fantastic and there is an internationally rapidly growing community of players now : ).

-- Felix Geisendörfer aka the_undefined

PS: Graham is uploading all CakeFest slides right now as well as writing articles covering the talks in detail.

Update 1: Just saw that Kevin also has a fantastic post on the things he picked up at cakefest.

Hey folks,

There are only around 10 hours left until sales close for the up until now biggest CakeFest. It will take place from Jul 9 until Jul 12 in Debuggable's hometown Berlin, Germany. It is in fact two events in one: A CakePHP workshop and the main conference with talks presented by core developers and community members.

The CakePHP Workshop

The CakeFest CakePHP Workshop (July 9-10) provides an opportunity for beginner and intermediate developers to jump-start their experience with CakePHP by learning directly from the CakePHP core team. Participants are strongly encouraged to bring their laptops, as they will be learning hands-on how to set up and build CakePHP applications.

Nate and Mariano will talk about topics including basic application design, expert project workflow techniques, interacting with databases and web services, JavaScript and Ajax, and much more. The presentations are classroom-style allowing participants to follow along and ask questions. Check out the workshop schedule.

Felix, others and myself will be on-hand to provide one-on-one help. If you are a designer and the workshop pace is quite fast for you or if you are experienced, but have a difficult architectural problem that you need help with: The workshop and the one-on-ones will get you up and running and will provide all necessary help.

The Main Conference

The CakeFest Conference (July 11-12) is the primere event for CakePHP developers of all levels to meet, socialize, and learn collaboratively. Attendees will be immersed in a collective learning environment where some of the coolest ideas of the CakePHP community will be discussed and presented.

Topics include - but aren't limited to - Demystifying Webservices in CakePHP, Building Custom APIs and JavaScript for PHP Developers. Check out the full schedule and head on over and get your ticket.

What do we do in the evenings?

The evenings will be packed with fun dinners, bar visits and club visits. If you thought discussions would end then you are wrong. The CakeFests from the past proved to have very enjoyable evenings with fun action going on.

How many folks will be there?

Just to give you an idea about how many folks will be attending. As of now there are:

• 9 people from the CakePHP Development Team
• 35 people attending the workshop
• 62 people attending the conference

.. attending.

So you can see, there are tons of opportunities to network, discuss and learn about new and old things. You will be able to meet core team members and discuss your applications, experience and wishes with them. In the evenings we will hang out, drink one or two beers, and just have fun! And all of that at affordable prices!

So, what are you waiting for? Hop on over and grab your ticket. :)

See you all there!

-- Tim Koschuetzki aka DarkAngelBGE