The Adventures Of Merging Propel With Zend Framework

Out Of Date Warning

Languages change. Perspectives are different. Ideas move on. This article was published on March 22, 2010 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.

Recently, I finished my first production-quality Zend Framework application. It was a new website that made use of an old backend that powers another application I wrote using a custom framework. I wanted to use Zend Framework to practice on it, and to learn things I hadn’t yet learned since I had yet to put an application into production; however, I didn’t have any desire to rewrite my model, which was done in Propel.

Propel has two things going for it already: the first is that Propel includes its own autoloader, meaning that I didn’t have to try and force Propel into Zend Framework’s file system structure. The second is that Propel is designed to let you put it’s files anywhere you want with ease, so long as you update your include path properly. This made the process significantly easier than I had thought it would be.

First off, I placed the Propel runtime components in the library/ directory. I decided to use an svn:external property to do this, since there was little point in my mind to having a copy of something available in another repository. Next, I created an svn:external property to my own model (which turned out to be in the same repository). This I placed under application/models and I simply called it propel.

I had a bit of a problem with the Propel configuration file, which contains mappings to the locations of various Propel elements (namely, the model classes). I had to create a copy of my old application’s configuration file, and edit it by hand to reflect the new location of the model classes. This was simple enough, as the model is fairly small. A larger model would take more time, but I would also be likely to simply use grep.

Next, I wrote my bootstrap method, which includes the Propel class file and initializes it:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{

    protected function _initPropel()
    {
        require '../library/propel/Propel.php';
        Propel::init(APPLICATION_PATH . '/configs/propel-conf.php');
    }

}

I still had a problem though: Zend Framework couldn’t find the model files. This is because Propel assumes that you’ve edited your include path to include the directory that contains the model directory. Therefore, I added $PATH/application/model to my include path in public/index.php. This worked perfectly.

All told it took me about an hour to hook up Propel to my Zend Framework install, and the magic of autoloading makes things much easier. While future projects will likely use Doctrine (especially with Doctrine 2 looking amazing), a strong desire to avoid rewriting the model kept me from migrating.

Integrating libraries into Zend Framework need not be a painful, terrible process.

Write better object oriented PHP today.

Object oriented programming always leaves you with a headache. What if you could master it instead?

Get the book now! »

Chris (@chris_linseman) wrote at 3/25/2010 4:43 am:

I recently finished doing the same thing, in a very similar way. I have a question though, did you update the propel runtime-config file to use values from your zend configuration? if so, how did you manage it?

I still have my DB config values in two places and want to change this.

Brandon Savage (@brandonsavage) wrote at 3/25/2010 7:21 am:

I haven’t yet integrated Propel with the ZF Bootstrap plugin paradigm yet. I’m planning on it at some point.

Jose Perales (@joseperales) wrote at 3/28/2010 5:14 pm:

Nice Share Brandon, I will do the same so How I can see, Let me use doctrine.