I chose CakePHP

I decided that it would be a good idea to use a framework. Why? Because those who use frameworks swear by them. The idea is that using a framework cuts down on repetitive coding tasks, which crop up most frequently with database-backed web applications (read: every site worth visiting). But they are very complicated to a beginner like me.

Why did I choose CakePHP instead of Zend Framework or Symfony? Well, I installed Symfony and CakePHP, both seemed to work well enough. Users of both frameworks seem to agree that the Symfony documentation is more complete, and each eyes the other as a worthy competitor (compare this to the Ruby world, where Ruby on Rails is virtually the only choice of framework). Basically, I completed the CakePHP blog tutorial, it worked, and I was hooked. No other reason than that. So there you have it: This web application will be built using the CakePHP framework.

Once I installed it and got it running properly, I tried to go through the manual, but many problems crept up, and I found myself copying code out of the tutorial without understanding ANY of it. It reads nicely: $this->Song['id']->save();. Save this song ID, right? Well not exactly. Turns out Cake basically obliges its users to code in PHP, and to do so in completely object oriented (OO) manner. Object oriented programming is great (so I've been told), but, just like everything else in PHP, I'd never done it. So I did a few google searches, completed a few tutorials, and got a loose understanding of the syntax and purpose of OOP. That made a huge difference. For example, I learned the difference between "->" (navigating inside an object) and "=>" (navigating inside an array). But I still wasn't really grasping CakePHP and all of the "$this" commands, until I had a major breakthrough: "print_r($this)." This outputs the contents of $this on to a web page so you can see the object, and navigate through it with your eyes. So simple, so important, yet I had never done it. More later.