Experiences with CakePHP
CakePHP is a rapid development framework for web applications. It can be seen as the PHP equivalent of Ruby on Rails.
Basic principles of both Ruby on Rails and CakePHP include:
- Convention over Configuration : if you stick to a basic set of principles (i.e. naming of database tables) you do not need
to configure much or anything at all to harness the full power of the framework.
- Don't Repeat Yourself : all (database-driven) web applications have a lot in common. Rewriting or copying and modifying all
of that code is tedious work and should be avoided. It's a basic programming principle to never write the same code twice. This
is true for programming on all sorts of levels, so it's just as true for a web application.
Developing with CakePHP
To develop a web application with CakePHP is very easy and quick. If you are familiar with the Model-View-Controller approach to programming will make it even more convenient. The Models in CakePHP are basically describing some data from some database. Defining a model is as easy as creating a file which contains a single class which is a subclass of AppModel. If you create a accompaning table in the database (use conventions for naming!), CakePHP will figure out how to save, edit, delete the data to the database. That means no more tedious writing of SQL queries in almost all cases.
I have no problems whatsoever writing SQL queries, it's just repetitive work and therefore unnecessary. CakePHP demonstrates this really good: define a database schema, tell it what stuff you have in the database and it will handle everything for you, from saving to retrieving. Extra bonus of this abstraction is possibility to use a variety of database software. You are no longer bound just to MySQL if you do not want to write a dozen different database abstraction layers. This makes deployment of the web application so much easier. If CakePHP can run on a given system, so can your application.
Controllers are responsible for actions on the data/models. It's really great to create a controller from a use-case point of view. If you have clear use cases for your website, you can just create a controller that handles operations on a specific model. Use-cases can be converted to so-called 'actions' by creating a corresponding function in the controller. Inside the function, data can be retrieved, modified, saved, whatever you want. The data or any other data/text will then be transported to the view automatically. The view is in most cases nothing more than a description of how to present the data. So most of the times it's a single file per action that contains a bit of html/css markup and insertion points for the data using PHP.
What makes it great?
If you adhere to the conventions set by CakePHP, developing a new web application can be done really fast. A lot of a web application's codebase can be reused in other applications. CakePHP makes great use of this by abstracting a lot of code. This way you can simply extend upon the CakePHP codebase where needed for your application. The beauty of CakePHP is that you can quickly develop custom web applications, whilst keeping control over every aspect of the application and thus keeping it almost completely custom.
Drawbacks
One of the few drawbacks I can currently think of is that you'll need to stick to conventions set by others to fully make use of the power of CakePHP. This can be frustrating at times, but once you get used to the 'CakePHP-way' it is a breeze to develop new database-driven web applications. Another drawback might be PHP's poor support for Object Oriented Programming that forms an important basis for CakePHP. The availability of PHP on hosting providers and good community surrounding PHP still makes CakePHP the best option for me. I personally didn't notice much of PHP's hacked OOP when using CakePHP. At points where Object Oriented support is failing, CakePHP makes good use of one of PHP's best features, being named array keys.