Danceric

This is a follow-up to my post: Doctrine ORM and the Zend Framework

ZFDebug is a debug bar for Zend Framework, largely inspired by the Symfony Debug Bar. I have created a ZFDebug plugin that displays informations form the Doctrine profiler in the debug bar. You can see the sample code on my GitHub repository for zfdebugdoctrine.

If you already know how to use ZF, Doctrine and ZFDebug, you can jump right to the zfdebug doctrine plugin file.

This is my notes on integrating the Doctrine ORM with a Zend Framework project that use Zend_Application. This post was largely inspired by the post Integrating Zend Framework and Doctrine. In fact, you can see mine as an updated version of this great post to work in ZF 1.8. Ruben Vermeersch, the author, have stated on his blog that he want to update the post but he don’t have the time yet, so this is me trying to help.

This was done on OS X, so the instructions here assume a n*x like environment. You should also be comfortable with Zend Framework 1.8+ and the new Zend_Application. As stated in the ZF quickstart tutorial, you can create a project by running this command from the uncompressed Zend Framework folder:

./bin/zf.sh create project ~/Sites/zfdoctrine

In the newly created directory, which is a complete zf application, create the directories that will be needed by doctrine

cd ~/Sites/zfdoctrine
mkdir doctrine doctrine/migrations doctrine/schema
mkdir doctrine/data doctrine/data/fixtures doctrine/data/sql

Now, put the content of the Doctrine (1.0 or 1.1) lib folder in library. I strongly suggest that you put the ZF library here too. If you manage more that one project, it’s very unlikely that you will have time to update all your projects at the same time, which is needed if you use a global include path.

Create the Doctrine configuration in application/configs/application.ini

;doctrine.connection_string = "mysql://root:pwd@localhost/zfdoctrine"
doctrine.connection_string = "sqlite:///" APPLICATION_PATH "/zfdoctrine.db"
doctrine.data_fixtures_path = APPLICATION_PATH "/../doctrine/data/fixtures"
doctrine.models_path = APPLICATION_PATH "/models"
doctrine.migrations_path = APPLICATION_PATH "/../doctrine/migrations"
doctrine.sql_path = APPLICATION_PATH "/../doctrine/data/sql"
doctrine.yaml_schema_path = APPLICATION_PATH "/../doctrine/schema"

Initialize Doctrine in you application by adding this function to application/Bootstrap.php

public function _initDoctrine()
{
    require_once 'Doctrine.php';        
    $loader = Zend_Loader_Autoloader::getInstance();
    $loader->pushAutoloader(array('Doctrine', 'autoload'));
 
    $doctrineConfig = $this->getOption('doctrine');
 
    $manager = Doctrine_Manager::getInstance();
    $manager->setAttribute(
        Doctrine::ATTR_MODEL_LOADING, 
        Doctrine::MODEL_LOADING_CONSERVATIVE);    
 
    // Add models and generated base classes to Doctrine autoloader
    Doctrine::loadModels($doctrineConfig['models_path']);
 
    $manager->openConnection($doctrineConfig['connection_string']);    
 
    return $manager;
}

One of the fun thing about Doctrine is that you have access to a lot of command line tool to create your database, models, sql, schema, etc. Create a new file called doctrine-cli in a scripts folder at the root of you project with the following content:

#!/usr/bin/env php
<?php
/**
 * Doctrine CLI script
 */
 
define('APPLICATION_ENV', 'development');
 
define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application'));
 
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    get_include_path(),
)));
 
require_once 'Zend/Application.php';
 
// Create application, bootstrap, and run
$application = new Zend_Application(
    APPLICATION_ENV,
    APPLICATION_PATH . '/configs/application.ini'
);
 
$application->getBootstrap()->bootstrap('doctrine');
 
$cli = new Doctrine_Cli($application->getOption('doctrine'));
$cli->run($_SERVER['argv']);

You can make this script executable and try it, to see the list of task that doctrine-cli can do for you

chmod +x ./scripts/doctrine-cli
./scripts/doctrine-cli

Now you can jump back to [Ruben Vermeersch's Tutorial]http://ruben.savanne.be/articles/integrating-zend-framework-and-doctrine) tutorial in the “Building an application” section and create the sample application. You’ll learn how to use Doctrine do a simple insert, a query and how to use the command line to create your database and model.

note: If you’re using these two projects together, you may be interested in my next post too: ZFDebug and Doctrine ORM

Since I have started using the Zend Framework, I have noticed a limitation in the Markdown parser. As there is classes with names such as Zend_Form_Decorator_Fieldset, and Markdown replace everything between underscore with emphasis, they get rendered like this: ZendFormDecorator_Fieldset. So I have switched to PHP Markdown Extra which fix this, and I have applied the same modifications as before to have syntax coloring.

My new patch for PHP Markdown Extra and GeSHi is availlable on GitHub.

Don’t forget to adjust the require_once line to your GeSHi folder location, and start your code block with the language name between square brackets. ie [PHP]

Also added, is the ability to use the parser from the commande line. If used from the command line with a valid file as an argument, it will ouptput the result to stdout, one sample usage could be:

markdown-geshi-extra.php README.markdown > README.html

One of the component in the Zend Framework that I’m learning to love lately is Zend_Http_Client. If I remember correctly, back in the days, my first reaction on this component was:

Oh, this is for just for those who don’t know how to use curl_* functions. I don’t need that, pff

Then somebody, trying to convince me to use it, told me:

but you don’t understand! this is usefull if your php was build without cURL support

I hate the ‘if your php is built without…’ family of excuses. And what about if my webserver don’t have the required PHP > 5.2.4 as needed by Zend, or if it’ is built without PHP support, or if my server is without an OS? I must confess that I have always (eh, mostly) been working with company that have enough control on their server to make it easy for the developers. I strongly think that to create something great, one need some control on his environment. Would you like to have a surgery by a surgeon who don’t have access to all his tools?

Back on topic. First thing first, Zend_Http_Client makes your code easier to read, even after a while. cURL argument are like regular expression, you never totally forgot them, but you need to look at the documentation once in a while. To me, the main advantage is that you can tell your http client to use different adapter. And my favorite these days is the Test adapter. As the name implied, it is really usefull when doing (unit) test.

Using the Test adapter, I can simulate an answer from a website. This mean that I can work on some Twitter stuff and test them anytime, even if Twitter seems to always be down at the exact same moment I want/need to try something.

Here’s an example that simulate a search request, you first start by getting an example answer with curl on the command line (when Twitter is up) that you save into dummy.json:

curl -o dummy.json -i http://search.twitter.com/search.json?from=danceric

and then use this file to set the response with the test adapter

$client = new Zend_Http_Client();
$client->setUri('http://search.twitter.com/search.json');    
 
// Set the expected response
$client->setAdapter(new Zend_Http_Client_Adapter_Test());
$fakeResponse = file_get_contents('dummy.json');
$client->adapter->setResponse($fakeResponse);
 
$client->setParameterGet(array(
  'from' => 'danceric',
));    
$response = $client->request();
 
//let's pretend I want the result as an array
$searchResult = Zend_Json::decode($response->getBody());

Now I can have a result returned without contacting Twitter. it’s easy to create a set of dummy data for your different unit test. Of course this code is not to be used as is in a unit test…

Btw, Twitter is not always down. It just seems worse when you use it too much.

I’ve just started building a niche video website for West Coast Swing to play with GitHub and the Zend Framework (v1.8).

The source code is available at github.com/danceric/subyt and the test website is at video.liveyourdance.com.

Please keep in mind that this is just a work in progress.

One of the easiest (ie: fastest) way to have a fully working LAMP development environment on OS X is to install Zend Server, which is a package containing apache/php/mysql/zend framework and some other goodies

There is a free version available on the Zend Server Community Edition web page

One thing you might want to do after the installation is to add the Zend binaries in your path before the OS X bundled php/apache binaries.

Add this line to ~/.bash_profile OR ~/.profile

# Zend Server Community Edition
export PATH="/usr/local/zend/bin:$PATH" 

Your webserver should now be available on port 10088 and the Zend admin interface on port 10081

Xdebug

Zend Server CE comes bundled with the Zend Debugger, which is nice when your boss gaves you a Zend Studio licence to use the great profiler. But for me, at home, I use some other editor/IDE (Eclipse PDT, Komodo, TextMate, Netbeans…). So, when I want to profile a script/application, I use Xdebug, which can be used with webgrind or KCachegrind to profile your web application. Oh, and XDebug provides this nice formating for var_dump()… how could I resist.

Installing Xdebug on Zend Server CE on OS X

Adapted from the Windows instructions at http://forums.zend.com/viewtopic.php?f=8&t=553

Save yourself some time and get the pre-compiled Xdebug binaries for OS X from Activestate. And while you’re there, you should download and try Komodo IDE/Edit if you have never done so.

From the archive, copy the file

5.2/xdebug.so

to

/usr/local/zend/lib/php_extensions/

Before using Xdebug though, you have to disable the Zend Debugger. Open the file

/usr/local/zend/etc/conf.d/debugger.ini

and comment the line starting with

zend_extension_manager.dir.debugger

by adding a semicolon at the start of the line

Now, to tell PHP that we’re using Xdebug, add these lines in /usr/local/zend/etc/php.ini just before the [zend] section

[xdebug]
zend_extension="/usr/local/zend/lib/php_extensions/xdebug.so"

Now if you restart your web server, you should see Xdebug in the View PHPinfo page link of the admin dashboard

sudo /usr/local/zend/bin/zendctl.sh restart-apache