CakePHP 3.0 is currently in the second Beta, so today we will go over the goals of CakePHP 3.0, some of the major changes and how you should start using it.
Goals of CakePHP 3
What are the goals of CakePHP 3? This is actually the easiest question to answer. The Cake core team provided that answer on the Github wiki. Lets review it:
- Use the standards already part of the PHP community and adopt them as part of CakePHP.
- Move away from the legacy of being tightly coupled. Any parts of the Cake core that can be de-coupled from the rest of the Cake core, should do so.
- PHP 5.4 is now the absolute minimum. PHP 5.3 is at the end of life and it is time to move into the present. Even PHP 5.4 will only be supported until 2015 according to the PHP core team.
- Make it more awesome and simpler. Cake has grown a fair bit over the years into the awesome framework that it is. However it could do with slimming down.
Each of these goals is working towards separate concerns the CakePHP and the broader PHP community has had with both frameworks in general and CakePHP specifically.
The broader PHP community has, through the PHP Framework Interoperability Group, worked to adopt standards that allow for solving a set of problems in a similar manner, for the frameworks and the broader PHP community to gain more cohesion than it has been known for in the past. FIG is working, in its own small way, towards eliminating the Not Invented Here Syndrome as much as it can and CakePHP is adopting some of the FIG’s standards.
The first goal is working to tackle this issue head on, installing and loading CakePHP packages. So say hello to Composer. As well as the general code standards from the FIG, PSR-0 and PSR-1.
CakePHP has gained a reputation over the years of being tightly coupled. To address these complaints, large parts of the framework are being decoupled and could even be used independently of Cake if so desired. If you’ve been wanting to use pieces of Cake without relying on the entire stack; this might just be the time to take a second look at Cake.
PHP has started picking up the pace in terms of dropping support for old versions of PHP and Cake needs to move along with the times. PHP 5.4 is currently the minimum install requirement for CakePHP 3.0. PHP 5.6 while being the actively developed version of PHP certainly wasn’t when Cake 3 started being developed. It is always a trade off between where the Cake community was a year or more ago when Cake 3 started being developed and where it and the PHP community are today. Cake is progressing at a rate that feels forward thinking without moving so fast companies that are relying on more stable server OS releases need to reconsider their server stack merely by updating to Cake 3.0. It should also be noted that at CakeFest 2014, the core team said they were most likely not going to keep every version of Cake 3.x stuck on PHP 5.4 and they could drop support for PHP 5.4 as the need arose.
Cake is a full stack framework but not everyone favors that. While CakePHP is not going in the direction of a fully slimmed down micro framework there are places where Cake could pull out features that aren’t needed by most everyone in the community. ACL is a perfect example of this. Not everyone needed ACL and attempting to hack ACL to solve your use case was troublesome. In Cake 3 ACL is now a plugin; if you want or need ACL feel free to use it, if you don’t forget it even existed.
Major Changes in CakePHP 3.0
With all these goals CakePHP 3 cannot maintain backwards compatibility and hope to move forward. The team has made some major decisions about where to improve the framework and they should be applauded for their decisions to do so. We will cover some of the changes that you will experience once you are using Cake 3.
Installation
If you weren’t on the Composer bandwagon before today, you are now. CakePHP 3 now supports only one method for installation, Composer. If you aren’t using it today, please go out and start learning it today. I even gave a presentation at CakeFest this year on using Composer with CakePHP today, that may be helpful.
Internationalization
This part of the CakePHP framework provides a great example of using tools from the general PHP community as part of Cake, rather that simply building in-house, so to speak. The I18n portion of the framework acts essentially the same as in Cake 2.x but instead the backend is all handled using the Aura.Intl package.
New ORM
This is the biggest change you will experience in your day to day development with Cake. I am only going to give a brief introduction to the full depth of changes here. The docs and this presentation should give a good idea once you start a new project. The basics we can cover here.
Cake 3 has a few new classes for dealing with used to be just the model; now you have a Table class, a Query class and a Entity class. There are a few others but those are the key classes of our new abstracted and layered Model component.
We now have more layers of abstraction in which to deal with a database table and the objects resulting from a query against the table. This provides more separation between the attributes of the table itself, the queries run on that table and the results returned from a query. To answer everyone’s complaint over the years, yes, results returned from a query are Objects, not arrays. This is all for the better, more powerful and expressive queries are more easily built with the advantage that the Model layer becomes more focused individual units of code. Anyone working with a decent size Cake application knows how quickly even a decent size model (Fat Models anyone) can become loaded with multiple callbacks, custom finds, virtual fields and then custom methods on top of all that. Models of any decent size were becoming extremely large and hard to test. Cake in moving to this multiple layer system is trying to slim down the Model layer at any one point and make your Model layer a little easier to code and test.
For any long term Cake developer this will be the largest change to handle, however based on my, to be fair, limited experience with the Cake 3 ORM at this point, it is one of the most productive changes. The model layer has always been one of the most logic heavy points in a Cake MVC architecture and Cake 3 is making the model layer even more powerful and expressive.
When do I start using it?
So now that you understand some of the goals and changes in Cake 3, when should you start using it? This is always a matter of “it depends on your team and timeline”. Loadsys is not currently building new applications with Cake 3 though we do have a few new applications in the pipeline. We are constructing these applications with the ideas of Cake 3 in mind and trying to build our applications in such a manner that they will be easier to upgrade. We place large pieces of the business logic in independent libraries outside of the Cake Core, so an upgrade of Cake will not affect them. Our controller stack is as skinny and simple as possible. Our model layer relies heavily on custom finds that should be relatively easy to swap out with the new ORM. No upgrade of a new framework is ever going to be painless but we are trying to minimize the pain points that we can ahead of time. Loadsys is aiming to upgrade these applications early in the Cake 3.0 lifecycle.
If you have an application that is needing to go live before Cake 3.0 is stable I recommend following this path. However if your application is small enough or an internal facing application that being on the Beta or RC versions of CakePHP 3.0 won’t hurt you, please, go build the application on Cake 3. Loadsys is building an internal application on Cake 3 to help provider feedback. Like all software, the more feedback from these pre-release versions of CakePHP, the better the final release will be.
If you have a project with a long pipeline, the final release being at least a few months out, I recommend you build the application today with CakePHP 3.0. Not only will you help improve the final release of CakePHP, you will have the advantage of being on the latest and greatest version of CakePHP and that’s never a bad thing. Also you will no longer need to plan on one upgrade as part of your development cycle.
The final situation is a long lived project that is in maintenance mode or still being actively developed on Cake 2.x. While you probably will not want or need to switch to CakePHP 3 as soon as it comes out, if the application is going to live for longer than a few years it will have to be updated, at some point. So consider trying to build it in such a manner that it reflects the changes coming down the pipeline; switch to Composer if you haven’t already, try to replace virtual fields and custom methods with custom finds, build out a solid collection of unit tests to catch issues when you do upgrade, etc. While you won’t eliminate all the pain points of an upgrade, learning the lessons of Cake 3 and trying to apply them where you can will make for a better application and an easier upgrade.
If for some reason you are still on Cake 1.x, just plan on a rewrite at this point. Whatever opportunity you had for performing an upgrade to Cake 2.x passed by a long time ago and rewrite is probably your only option if you want to try keeping up with either PHP or Cake.
The Cake core team has done a superb job in CakePHP 3.0 and it is great to see all of these changes making CakePHP a still excellent choice for anyone looking for a full stack, convention over configuration PHP framework.