Coding Club

Dear all,

The following technical contribution article is all about CakePHP written by Richard Nguyen for the sharing purpose in accordance with our Coding Club’s spiritual norm - “profoundly increasing, developing and riching people’s knowledge so as to effectively assist our coding lives and future careers with more eases.” - For such actively efforts, hopefully to give you a broader view and comprehensive savvy on general perspective aspects of this really stunning and engaging PHP Framework out there - The CakePHP Framework.

Technical Contribution Article on CakePHP

According to a recent study, PHP is one of the most popular programming languages in the world. In spite of this, PHP is often criticized for its inconsistent naming conventions, its lack of important features as compared to other languages (like namespaces) and its inherent disorganization. Furthermore, PHP is very easy to learn, and this has often led to the common misconception that most PHP developers are inexperienced and that their code is therefore prone to security vulnerabilities and exploits.

This is all true, to a certain extent. PHP itself offers virtually no real structure or organization, and thereby leaves coders free to express themselves in the most unpredictable and dangerous ways: programming logic mixed with presentation elements, disorganized inclusion of other source files anywhere in a script, unnecessary and often forgotten database connections, and so on. These are obvious and common mistakes that can make PHP code completely unmaintainable.

PHP Needs a Framework

In recent years, PHP has re-invented itself, allowing Object Oriented Programming (OOP) to enter the scene with a plethora of new rules and functionality, all of which are ingrained in more mainstream programming languages like C++ and Java. Gradually, more and more PHP developers have embraced this new philosophy and started developing frameworks, drawing their inspiration from other more-established languages in the pursuit of creating a structure for an inherently unstructured language.

Many frameworks are available on the Internet, each with its own specific set of rules and conventions, achievements and failures. Some degenerate into unusable and intricate collections of pre-built libraries and tools that enslave developers into complex and truly unusable programming methodologies; others do not.

Ruby on Rails has definitely played a key role in inspiring the quest for the perfect web framework in programming languages other than Ruby. Thanks to the Rails phenomenon, more frameworks have appeared on the scene, offering functionality that’s very similar to Ruby on Rails. These frameworks are often labeled Rails Clones.

Some of the frameworks’ developers have openly admitted that they tried to port Rails to other languages, but often they overlook the fact that Ruby on Rails was built in Ruby for a reason: Ruby has features that no other programming language offers. At the same time, at least one person gave up on the idea of totally cloning Rails in PHP, but instead, decided to borrow its structure and basic concepts to make PHP more organized:

While it’s difficult to copy Rails in PHP, it’s quite possible to write an equivalent system. I like the terseness of Ruby code, but I need the structure that Rails provides, how it makes me organize my code into something sustainable. That’s why I’m ripping off Rails in Cake.

- CakePHP’s founder, commenting on a famous blog post.

This is what makes CakePHP not only different, but one of the most popular frameworks for PHP: its modest, yet important goal is to provide an appropriate structure for PHP applications.

CakePHP’s Approach to the MVC Architecture

Readers who already know Ruby on Rails may find CakePHP very similar to it. For one thing, Cake is based on an MVC-like architecture that is both powerful and easy to grasp: controllers, models and views guarantee a strict but natural separation of business logic from data and presentation layers.

Controllers contain the logic of your application. Each controller can offer different functionality; controllers retrieve and modify data by accessing database tables through models; and they register variables and objects, which can be used in views.

Models are active representations of database tables: they can connect to your database, query it (if instructed to do so by a controller) and save data to the database. It is important to note that in order to correctly apply the MVC architecture, there must be no interaction between models and views: all the logic is handled by controllers.

Views can be described as template files that present their content to the user: variables, arrays and objects that are used in views are registered through a controller. Views should not contain complex business logic; only the elementary control structures necessary to perform particular operations, such as the iteration of collected data through a foreach construct, should be contained within a view.

This architecture can greatly improve the maintainability and the organization of your site’s code:

It separates business logic from presentation and data retrieval.
A site is divided into logical sections, each governed by a particular controller.
When testing and debugging an application, any developer accustomed to CakePHP’s structure will be able to locate and correct errors without knowing all of the details of the code.

Controllers, models and views are stored in pre-defined directories within CakePHP’s directory structure. Here’s the directory structure that’s used:

app/
config/
controllers/
models/
plugins/
tmp/
vendors/
views/
webroot/
cake/
config/
docs/
libs/
vendors/

This directory scheme must be preserved, as it is essential if the framework itself is to work. Cake, like Rails, believes in the importance of convention over configuration: in order to deploy an application, rather than modify dozens of different configuration files, it’s important only to place everything in its proper place; then, you can let the framework do the rest.

Although this may seem worrisome for some developers, it’s a good compromise that can really accelerate the development process.

Best regards,
Richard Nguyen