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.

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);
      }
  } 

The code is on github at: http://github.com/danceric/wave-hangman

P.S.: As always, keep in mind that this was done to learn a little more bit about Google Wave and Python, so don’t expect the best game ever.

P.P.S.: I know the name danceric-hangman may sound self-centered, but it’s hard to find a free appID on appspot nowadays.

• you have interest in all aspect of web dev. ie: design, css, javascript, html, xss, crsf, rest, etc
• you know how to use the command line and how to setup/configure your own dev server
• you have some code of yours on a public repository (github, sourceforge, bitbucket, etc)
• you understand the bus factor and make sure your code/app can survive without you
• you’re taking a little bit more time to make sure you will save time in the long run
• you express your opinion/ideas publicly and appreciate/want feedback
• you aim for “The Simplest Thing That Could Possibly Work”
• you know that learning is part of your everyday job
• you have a technical blog/twitter/whatever trendy
• you are reading web development news website
• you are reading some general tech sites too
• you know that you don’t know everything
• you go out to local tech event
• you are open to new idea

and most importantly

• you’re not doing it only to pay your bills

If you answered “yes”, or better “of course” to most of these, then you’re probably an interesting coworker to have for a web developer. (this is only true, of course, if you don’t think you’re better than everyone because you’ve answered yes to these questions)

I’ve build a simple blog (you know, ‘blog’ is the new ‘hello, world!’) using the webapp framework on Google Appengine (code/demo). Next planned steps are, in no particular order:

• finish reading (the dead tree version of) The Django Book and port a web app of mine to Django
• take the Python Challenge
• read Think Python
  
  

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.