Early work has started for CakePHP 3.0, and I’ve started re-visiting how CakePHP handles configuration and bootstrapping. I want to focus on configuration for this post, as bootstrapping, while related is worthy of its own post. The goal of this post is to provide some context on the planned changes, and to get feedback on those changes. My hope is that by getting feedback early on we can avoid problems & surprises later on.
In the last article I went over the various static analysis tools I’ve found useful, and how to get them installed. For this installment, I’ll be going over how to use make to run all the tasks, and how to configure all the tools to work with Jenkins.
I’ve recently integrated static analysis tools into both my day job’s and CakePHP’s development process. Setting up static analysis tools is reasonably easy and can help you find problems before you even get to unit tests, or staging sites. They are also the ideal tool to help enforce coding standards, and best practices that can be checked by reading the code.
One of the new features in CakePHP 2.1 I am excited about are view blocks and view inheritance. Both are concepts borrowed from Jinja2 and other templating systems. Template inheritance allows you to create skeleton views, and define blocks to populate that skeleton in a child template.
CakePHP uses salted sha1 hashes for passwords by default, and has for a while. There has been some talk on the mailing list lately of switching the default hashing to something more secure, such as bcrypt. I think this is a great idea, and will find its way into CakePHP in a future release. Providing a reasonanle upgrade experience is the biggest problem to solve, if the default hashing strategy was to change.
In case you were not able to attend CakeFest 2011. I’ve posted my slides up on slideshare. The event was a great success. Thanks to Graham for organizing the event and to all the attendees. Its great to meet the community and put faces and names to irc handles and mailing list email addresses.
This week I’ve been participating in the SQLServer Jump-in Camp. My focus for the workshops have been building out better support for IIS and SQL Server in CakePHP. As I generally develop on MacOS, I do development for other platforms through virtual machines. This has worked well with linux servers in the past.
In a previous article I covered how CakePHP would potentially be moving to using sphinx for the 2.0 documentation. Myself and some of the other CakePHP developers have been working on this option, and seeing if it has any legs. Turns out that sphinx is actually a pretty great tool.
In the release announcement for 1.3.7, it was tentatively announced that CakePHP would be moving its documentation over to ReST, Git and sphinx. Having documentation in a git repo, and using sphinx to generate documentation has a few nice wins, that would be difficult to achieve with the current book application.
This time last year, amid rumours that the end of CakePHP was nigh, CakePHP died and rose from the dead . The year that followed those events, has been a very exciting one. CakePHP continues to be a thriving project with huge popularity, and a growing community. This year has a number of milestones as well.
Previously I wrote about the changes that have been done for the request handling in CakePHP 2.0. Response handling is another subsystem that has received a significant facelift. As with request information and functionality, response related features were spread across several objects. Controller, RequestHandler and Dispatcher all had a slice of the pie.
Work on CakePHP 2.0 is moving along, and I wanted to take some time to discuss and explain one of the sizeable refactorings that has been done for 2.0. In previous versions request parameters were just a bunch of arrays that were copied to the various places they were needed in the framework.