It’s great to see that PHP is gaining maturity lately. After the release of version 5.3 that have introduced namespaces, it’s now time for some of the biggest php projects to get together to discuss and agree on a common autoloader standard. This really nice project would allow interoperability between frameworks/projects.

Take a look at the proposal PSR-0 and try the autoloader on your new project. The more people using it, the easier our life will be as a PHP developer.

Note: if you want to give feedback to the group about the proposed standard, you’d better do it on twitter or on your blog, because there seem to be some not so clearly defined rules to be able to join the group… update 2009-11-11: thanks to Nate Abel there is now a public Project Acceptance Guidelines posted so this comment doesn’t hold true anymore. Thanks Nate.

Note 2:: if you’re wondering how nice your code could look by using namespaces in php, check out the lithium framework (#li3) for a good example.

Deprecated: This code uses an old version of Doctrine and Zend Framework, there is now an semi-official way of integrating Doctrine and Zend Framework, see the announcement of the zf-doctrine project and checkout my plugin for ZFDebug to have access to the Doctrine Profiler: http://github.com/danceric/zfdebugdoctrine

—

I’ve talked about that before on this blog. Using Doctrine 1.1 with ZendFramework 1.8 and using both with ZFDebug. Now things will only get better as both project will officially play nice together. Here’s the announcement on the Zend Framework mailing list.

This is some pretty good news, the other good news is that you don’t have to wait until the integration is ready to start playing with both. I’ve been testing out the alpha3 release of Doctrine 1.2 and I’m pleased to see that it’s really PEAR friendly, which make it a breeze to use it with the Zend Framework (that wasn’t as easy with Doctrine 1.1).

you can follow along with the code on github of my demo app: github.com/danceric/zfdebugdoctrine

First thing, the base doctrine class have been moved from /Doctrine.php to /Doctrine/Core.php, which mean that the Zend autoloader can now find it without special config/hack, just add Doctrine_ as a namespace and let ZF do the magic. This can be done in your application.ini with this single line

autoloaderNamespaces[] = "Doctrine_"

Second thing, which is the nice part, is that there is now a PEAR Style Model Loading and Generation, which means that the Doctrine cli can now generate models that can be autoloaded by ZF too. To generate your model from a yaml file (in ./doctrine/schema/schema.yaml`, you can run the doctrine-cli script like this

php ./scripts/doctrine-cli generate-models-yaml

and they will be generated in ./application/models. Note the generate_models_options array of options that define how the model classes will be named. Now, If you wish, you can move the models around to put them in a module by prefixing the classname with modulename_ as you would normally do. If you love spending more time in php land, you can build your model directly in php instead of the yaml file, just by extending the Doctrine_Record class. Check out the Doctrine Documentation, it’s really easy to do.

One thing to keep in mind, just as your web pages read the environment setting (APPLICATION_ENV) from ./public/.htaccess or ./public/index.php, the command line script for doctrine have to be set to use the expected environment too (3rd line of the script).

Once again, here’s the link to the working application that use Doctrine 1.2alpha3, Zend Framework 1.9.5 and ZFDebug 1.5

github.com/danceric/zfdebugdoctrine

Short ‘n Sweet Version

• start a ZF project

• add the doctrine namespace to your autoloader in your application.ini

  autoloaderNamespaces[] = "Doctrine_"

• connect to a database in your boostrap as

  $manager = Doctrine_Manager::getInstance();
  $manager->openConnection('your-connection-dsn');

• Create your models in the application/models folder by having class that extends Doctrine_Record

  class Model_Base_Post extends Doctrine_Record
  {
      public function setTableDefinition()
      {
          $this->setTableName('post');
          $this->hasColumn('id', 'integer', 4, array(
               'primary' => true,
               'autoincrement' => true,
               'type' => 'integer',
               'length' => '4',
          ));
          $this->hasColumn('content', 'string');
      }
   
      public function setUp()
      {
          parent::setUp();
          $timestampable0 = new Doctrine_Template_Timestampable();
          $this->actAs($timestampable0);
      }
  } 

I now mainly develop web applications using the Zend Framework, but some years ago, I was really grumbling about it, for what I thought was over-engineered structure and useless MVC crap… things have changed since then…

To make a long story short, I’ve started doing PHP when it was at version 3. No need to say that my programming style has evolved since. Back in the day, spaghetti was trendy and cool… When I was a mediocre programmer, I’ve tried the early releases of Symfony and Zend Framework (before their 1.0 release). My first experience was rather unpleasant. All these useless bloated object standing in the way of fast development… I’ve seen the light since, but with the help of a lesser known/used framework. The first framework that really helped me change my mindset from spaghetti programming mode to the framework way was CodeIgniter. This is a small framework with a really clean documentation. I know that some other frameworks have excellent documentation too (hello Symfony), but the codeigniter documentation is (was?) so small and concise that you can go through it in an afternoon and find out what are the MVC, ORM, and all the other goodies the cool kids are talking about.

Let me emphasis this important part:

I had to change my mindset to the framework way of doing things

And CodeIgniter was really helpful for that. I don’t use it anymore though, I don’t think it’s a bad framework, but I prefer OOP and I don’t need PHP4 support on my projects. My favorite PHP framework nowadays (ie: the one I can develop faster with) is Symfony, but I work with Zend Framework on a day to day basis now, and the learning curve for these two was way smoother after playing with CodeIgniter. Why I’ve chosen to focus on ZF instead of Sf? This will be the subject of a future blog post…

To summarize my advice: If you have tried Zend Framework and it appeared too big and useless to you, start with a smaller full-stack framework, just to get in the mood. You’re journey’s gonna be way easier starting from there.

You are developing with PHP 5 and you’ve got the free Zend Server Community Edition on OS X installed? Now you want more, you want a great IDE for free too? Sure the newly released Zend Studio 7 looks nice, but it’s not cheap. Luckily it’s based on Eclipse PDT 2.1, and this one is free. Of course there’s some things missing when you get stuff for free, like PHPUnit Integration and Zend Framework integration.

The good thing about Eclipse is that it can be customized easily to work with external tools. Making it really easy to add features to your editor. Let’s see an example:

PHP_CodeSniffer

PHP CodeSniffer is a tool that analyze your code and give you error and warning about what to change in it to make it standard compliant. It is a great learning to as it force you to understand, and it doesn’t make any change to your source code.

If you have installed Zend Server CE, PEAR will be already installed and ready to go. It should be the latest version, but you may want to make sure by running

/usr/local/zend/bin/pear channel-update pear.php.net
/usr/local/zend/bin/pear upgrade pear    

Now you can install PHP_CodeSniffer:

    sudo /usr/local/zend/bin/pear install --alldeps PHP_CodeSniffer

The external tool can be added from this menu entry:

menu > Run > External Tools > Open External Tools Dialog...

Select ‘Program’ and press the ‘New’ button to create a configuration.

name: PHP_CodeSniffer
main > Location: /usr/local/zend/bin/phpcs
main > Arguments: --standard=PEAR "${resource_loc}"
Common > check the 'Allocate Console'

The last step is to add this tool to your ‘External Tools Favorites’ by selecting

menu > Run > External Tools > Organize Favorites...

Click add and then choose you PHP_CodeSniffer tool. Now it should be available in the Run > External Tools menu, and in the corresponding icon in the toolbar (green circle with a white triangle in it, and a suitcase).

Setting up an external tools could be more user friendly, but keep in mind that your gonna do this configuration only once, as you will be able to launch it with a single click once configured.

Sky is the limit

This was just a simple example with PHP_CodeSniffer, but it can easily be applied to your zf.php script if you’re into the Zend Framework, or the phpunit or doctrine command, or anything you can think of.

Thanks to Björn Schotte at http://mayflower.biz, I have received my Planetary-sized Zend Framework poster. Yes, they shipped it as far as Ontario in Canada, thanks guys. It’s the perfect cheat sheet for ZF, and it’s great to cover a large and boring grey wall.

Just to give you and idea of the size of the poster, here’s a picture of my trying to hide it

By the way, if you don’t know what I’m talking about or if you want yours, just check out their blog post at thinkphp

Deprecated: This code uses an old version of Doctrine and Zend Framework, there is now an semi-official way of integrating Doctrine and Zend Framework, see the announcement of the zf-doctrine project and checkout my plugin for ZFDebug to have access to the Doctrine Profiler: http://github.com/danceric/zfdebugdoctrine

—

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.

update 2009/10/29: This was build with ZFDebug 1.5, Zend Framework 1.8 and Doctrine 1.1, you can check out Doctrine 1.2 is Zend Framework friendly too.