Danceric

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.

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.