This series is designed for PHP developers who want to start using a framework, but have not examined the available frameworks in detail. This series examines why the three frameworks under examination were chosen, how to install each of the frameworks, and you'll get a good handle on the test application that you're going to extend in each framework. It might sound like a lot, but don't worry — we break it down into manageable chunks.
Part 1 of this series lays out the scope for the series, introduces the frameworks being examined, covers their installation, and scopes out the first test application you will build. (Phew!)
Part 2 walks you through building the sample application in each of the three frameworks, highlighting their similarities and differences.
Part 3 starts with extending the test application, then deals with exceptions to the rule. All frameworks work well when doing the tasks for which they were designed. Needing to do something the framework wasn't built to do happens on every project. This article looks at such instances.
Part 4 focuses primarily on Ajax support. The use of Ajax, using native code and third-party libraries, is examined — specifically, how each framework behaves and accepts specific popular libraries.
Part 5 deals with working outside the frameworks. A single task is identified (nightly update script), and the process for accomplishing this task is examined in each framework.
This article has a lot of material. You must get up to speed quickly. There are three frameworks under examination. Which three? Why these three? What other frameworks are there? Why not those, instead? So many questions! But you'll get most of them answered before you go through the installation process for each framework. Then you'll learn about the test application used in the subsequent parts of this series. Right away, you'll start to get a sense for how the different frameworks differently and what kinds of things they do the same.
Before you begin, you need to have an environment in which you can work. The requirements are fairly minimal:
- An HTTP server that supports sessions (and preferably mod_rewrite) — This series was written using Apache V1.3 with mod_rewrite enabled.
- PHP V5.1.4 or later — Not all the frameworks being examined require this release level of PHP, but for the sake of ease, all frameworks will use the same PHP installation. This series was written using PHP V5.2.3.
- A reasonably recent installation of MySQL — Several other database options are available and supported, but both this series and the sample application were written using MySQL V5.0.37.
- An operating system that supports PHP V5.2.4 or later and MySQL — Linux® is used in this series. If you are a Windows® user, you will need to make obvious adjustments, especially when creating the directories mentioned below.
It is assumed that you already know PHP, application design, and how to work in a database. It's not necessary to have used a framework before, but you should certainly be ready to jump in with both feet.
Before talking about which frameworks were selected, it's worth talking about what a framework is.
The idea behind a framework is to offer a design you can use across multiple applications. All applications have a number of basic things in common — specifically, some kind of interface with a database, some amount of application logic, something that presents the application to the user. If you've written many PHP applications, you know what this looks like. You've probably written a set of functions or a class that reads and writes data from the database. You might have used a templating engine like Smarty to manage your UI. You've certainly written a bunch of PHP code that did things like analyze form submissions and make decisions based on submitted data. And if you've written many applications, you've probably done the same basic things over and over, sometimes stealing code from one application to use in another.
A framework is designed to provide a structure for these common elements (database interaction, presentation layer, application logic) so you spend less time writing up database interface code or presentation-layer interfaces and more time writing the application itself. The architecture represented by breaking an application up in this fashion is referred to as Model-View-Controller (MVC). Model refers to your data, View to your presentation layer, and Controller refers to the application or business logic. A full discussion of MVC is outside the scope of this article, but you are encouraged to research MVC and learn what all the fuss is about (see Resources).
There are several frameworks available for nearly every language. Selecting the right one for your needs can be somewhat difficult, especially if you haven't used any of them before. While advice and opinions from colleagues and trusty developerWorks authors can be helpful in this area, there is really only one guiding principle that should be followed when selecting any framework: A framework is only as good as the amount of time and effort it saves everyone. A framework is no good if it works well for you but causes a significant increase in support calls. A framework is no good if it is easy to support, but hinders rather than assists your development. A framework is useless if it is elegant, but causes support and development issues.
When selecting a framework for your project, consider everyone involved, from the top down, and when you evaluate the framework, keep the impact to other parties in mind.
When you consider adopting a framework, look at your application closely and ask yourself it if needs a framework. A framework isn't a necessity. Enterprise applications will continue to be written without the use of frameworks. Will a framework help you with the project? Will it save everyone time and effort? Will your application perform better on a framework? Will it provide the stability you are lacking? If the answer to any of these questions is yes, you should look to adopt a framework. If the answer to all of these questions is no, a framework will only complicate matters.
Unfortunately, size and scope restraints do not allow for a comprehensive coverage of all available PHP frameworks. This series focuses on three frameworks:
- Zend Framework
These were selected based on a variety of factors, but might be best classified as "The One Your Boss Knows About," "The One Someone Else Already Installed," and "The One They've Been Talking About." I encourage you to research CodeIgniter, Seagull, Web Application Component Toolkit (WACT), PRADO, Zoop, PHP on Trax, or any of the many other PHP frameworks available. Framework selection is very much a personal choice, much like selecting a language in which to code. This series isn't going to tell you which framework is better, or worse, than the others. Where a framework does something well, it will be called out. Where a framework seems unwieldy, this will be called out, as well. Even if we are not comprehensive in our coverage of the myriad frameworks, the approach we take will help you weight the strengths and weaknesses of other frameworks. You need to form your own opinions about the frameworks being examined, which ones you like, and what you decide to pursue.
Everyone knows Zend — "The PHP Company." When you download and install PHP, you're downloading it from Zend and have been since around V3. In addition to distributing PHP, Zend Technologies has offered a wide range of PHP support technologies over the years. It should be no surprise that Zend offers a framework for PHP — a popular one at 2 million downloads to date. If your boss has heard of a PHP framework, the Zend Framework is likely to be the one.
Sponsored by Sensio, symfony "aims to speed up the creation and maintenance of Web applications, and to replace the repetitive coding tasks by power, control and pleasure." The symfony framework has been used worldwide in a number of enterprise-level applications, perhaps most notably Askeet and Yahoo! Bookmarks. Odds are that if someone you know has installed, used, or played around with a PHP framework, that framework was symfony.
Borrowing heavily from Ruby on Rails, CakePHP aims to bring simplicity and scalability to PHP frameworks. Consistently recognized as a top PHP framework, CakePHP was recently selected as the core around which V5 of the Mambo Content Management System. Driven by a strong community and a rapidly growing user base, CakePHP's popularity is growing steadily. If you've overheard a conversation about PHP frameworks, that conversation was probably about CakePHP.
Each of the frameworks has its own set of installation instructions, and a thorough discussion of installation particulars is outside the scope of this article. Each installation will be highlighted, calling out the high points that may not be covered in each individual framework's installation instructions, or where deviation from these instructions is necessary due to the particulars of installing all three on a single machine.
Begin by creating a folder to hold all the code, frameworks, and includes you will need for this series (for example, a directory called /column). In this directory, create four additional directories: htdocs, protected, include, and src. Edit your Apache conf file so the document root points to /column/htdocs — and while you're there (if you haven't already), you should enable mod_rewrite. Edit your php.ini conf file to include the /column/include/ directory in the include_path directive. Don't worry if this all doesn't make sense yet. As you install the frameworks, all will become clear.
Download the Zend Framework (see Resources). This series was written using V1.0.1. Download and untar/unzip the Zend Framework into the /column/src directory. The distribution will contain a number of text files and three directories: demos, tests, and library. Copy the contents of the library directory (this should just be a folder called Zend) into the /column/include/ directory. You should now have a folder called /column/include/Zend containing a number of directories and files. These are the libraries used by the Zend Framework.
That's it! You've installed the Zend Framework.
Download symfony (see Resources). You are free to install symfony via any of the methods listed on the download page, though for our purposes, it's recommended that you download the tarball. Unpack the tarball into the /column/src/symfony/ directory. You should wind up with four directories (data, doc, lib, and licenses), as well as some README docs. Not all of these are necessary for installation of a finished application, but for now, they will be fine. That might seem too simple for an installation. Keep in mind that these frameworks generally consist of utilities and libraries, so getting them installed isn't difficult. Using them will take a little more configuration. This will become clear later.
Not everyone has the option of using PHP Extension and Application Repository (PEAR) installation in their environment, which is why we refer to the installation method above. However, if you can use PEAR, by all means, do so. Both methods are described on the symfony installation page (see Resources).
Download CakePHP (see Resources). This series was written using the 184.108.40.20627alpha version. The 1.2 branch of CakePHP, despite being a mature alpha, has been widely adopted by the CakePHP community as the norm. Download and unpack the tarball, placing the contents in /column/src/cakephp. You should wind up with four directories (app, cake, doc, and vendors), as well two files (.htaccess and index.php). You will be moving some of these files around later, but for now this is OK.
You've downloaded and installed three frameworks. But you'll have noticed that you didn't really do anything with them yet, like verify the installations with a Hello World application. That's because you're going to jump right past Hello World and into something a little (but not much more) meaty.
Building a Hello World application in a PHP framework can be a little painful. Using a framework involves some overhead, and that overhead gets in the way when you're trying to do something simple like Hello World. But that same overhead should seem like a well-spent expense when dealing with more complicated applications.
The test application you will build isn't much — yet. It's going to allow you to post text to the application using a text area. That text will be saved in a database and retrieved by the application for display on request. Using such an application, one would be able to easily create and update content on his Web site without having to edit HTML or upload new files. This highly innovative and ground-breaking application will be called Blahg.
What does Blahg look like?
Based on the description of Blahg, you have probably inferred several things about how the application will be designed. Blahg needs four elements:
- A page that contains a form — This form will need to contain at least a text area. This page will be the write page.
- A page that reads a post — This page will need to be passed some kind of post Identifier. This page will be the read page.
- A page that lists the available posts — This page will be the index page.
- A database table to hold posts — This table will need to at least hold the post text and the post identifier, and probably a Post title and the post's last-modified date.
Obviously, Blahg could be much more robust than this, and later in the series, you'll do a number of enhancements. But for now, let these simple requirements suffice. Unfortunately, you're not going to get a chance to build Blahg in any of the frameworks just yet. That comes in Part 2. But now is a good time to set up the databases you will be using.
Before you can really build Blahg, you need to get the databases set up. It's not at all necessary to set up a database for each individual framework, but for the purpose of this series, it will help keep things a little more organized while avoiding the necessity for table prefixes.
Create three databases, called Zend, symfony, and Cake, and grant full rights to each database to an appropriate user. The instructions for each framework below will contain the SQL necessary to create the posts table.
While you're in there fiddling with the databases, you may as well create the tables that Blahg will use in the beginning. Create a posts table in the Zend and symfony databases using the following SQL.
Listing 1. Creating a posts table in Zend and symfony
CREATE TABLE 'posts' ( 'id' INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY , 'title' VARCHAR( 255 ) NOT NULL , 'text' TEXT NOT NULL , 'modified' TIMESTAMP ON UPDATE CURRENT_TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINE = MYISAM ;
For Zend and symfony, you're leaving the maintenance of the modified column up to the database. For CakePHP, you're going to use a slightly different SQL. Doing so will allow Cake to perform some magic on your behalf (specifically, CakePHP will maintain the modified column automatically).
Listing 2. Creating a posts table in CakePHP
CREATE TABLE 'posts' ( 'id' INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY , 'title' VARCHAR( 255 ) NOT NULL , 'text' TEXT NOT NULL , 'modified' DATETIME DEFAULT NULL ) ENGINE = MYISAM ;
That is about as simple as table syntax can get. Based on how these tables look, you should have a pretty clear image for how Blahg is going to look and work. You might even try your hand at building Blahg yourself.
Resist the temptation to jump in and start fiddling with the frameworks right away. Instead, take some time and build Blahg without using any frameworks. Write it the way you are accustomed to writing your applications, whatever way that may be. Just be sure to stick to the requirements listed above while building Blahg — don't get too fancy yet. By building up the test application outside the context of a framework and modifying the application to include the enhancements you build throughout the series, you can give yourself a good gauge for how well a given framework suits your needs and how well a given framework fits with your development style.
We covered good ground here. I hope your installations went smoothly, but if you ran into any issues, you should dig into the installation documentation for each respective framework (see Resources). Take the time to build up Blahg according to the instructions above. It will be time well spent.
Read the rest of this "PHP
See the Zend Framework manual.
Get the symfony documentation.
Check out the CakePHP Manual (Note: The manual is
written to CakePHP V1.1. There may be some variance as you are using CakePHP V1.2).
Read the five-part series "Cook
up Web sites fast with CakePHP."
Visit Wikipedia for a high-level view of software
Get on overview of the MVC architecture from Wikipedia.
Refer to the PHP Manual for more information.
Visit PHP.net for additional PHP documentation.
For tutorials about learning to program with PHP, check out the developerWorks
"Learning PHP" series.
PHP.net is the central resource for PHP developers.
Check out the "Recommended PHP reading list."
Browse all the PHP content on developerWorks.
Expand your PHP skills by checking out IBM developerWorks' PHP project resources.
To listen to interesting interviews and discussions for software developers, check out developerWorks podcasts.
Using a database with PHP? Check out the Zend Core for
IBM, a seamless, out-of-the-box, easy-to-install PHP development and production environment that supports IBM DB2 V9.
Stay current with developerWorks' Technical events and webcasts.
Check out upcoming conferences, trade shows, webcasts, and other Events around the world that are of interest to IBM open source developers.
Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
Watch and learn about IBM and open source technologies and product functions with the no-cost developerWorks On demand demos.
Get products and technologies
Download PHP V5.2.3.
Innovate your next open source development project with IBM trial software, available for download or on DVD.
Download IBM product evaluation versions, and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
Participate in developerWorks blogs and get involved in the developerWorks community.
Participate in the developerWorks PHP Forum: Developing PHP applications with IBM Information Management products (DB2, IDS).