PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

recent work with zend framework and doctrine2

Note: This article was originally published at Planet PHP on 5 September 2010.
Planet PHP

I recently began working with an organization and we are in the midst of making some changes. They were not far enough along that any changes now make that much of a difference, but it was an odd set of changes nonetheless.

Initially, the client had started with CodeIgniter (during a phone call earlier, there was interest in ZF2, but when I started they'd gone with CI). One of the first things I tried to do was to get unit testing set up with CI, and the CIUnit failed out of the box. We're using PHP5.3, and apparently CIUnit doesn't work well with PHP5.3. I was on the fence about whether we should try to use a vanilla phpunit setup, but I counseled against it (was that wise?). CI was not hurting anyone, but it's also PHP4 compatible (still), which strikes me as a drag. I can't quite put my finger on it, and I know that aour' code can still take advantage of PHP5 stuff. However, with things like split() being deprecated in 5.3, I think we might start seeing more warnings if/when we started exercising more of CI. I might be wholly wrong though. I had a bad experience (multiple) with Kohana, so don't go there.

I've had zfkit in place for a while now, and suggested we look at that. However, zfkit has doctrine1 integrated, and the code the client had was already built around doctrine2. That took a little bit of cajoling to get working - once I'm a bit more comfortable with it, I plan to roll in doctrine2 support in to zfkit. I was a bit surprised to see some of the more useful aspects of doctrine1 were removed - the aacts as timestampable', for example. The authors disagreed that something like that is fundamental, and offer some ways around it, but those workarounds are fairly inelegant, imo. The more I work with doctrine2, the clumsier this sort of stuff feels in PHP. Yes, I know, the language itself is the impediment, and that's why many of my recent projects have been in Grails instead of PHP. For basic work, GORM is a lifesaver compared to doctrine and other PHP ORM tools. That said, phpunit is miles faster than unit testing in Grails, so there's always tradeoffs. Also, this client has chosen to do their doctrine definitions in php docblock annotations. They irk me.

Still, we'll have managed to port over the base of the existing app, have a replicatable(?) data story (drop/update schema, load test data) and the start of unit tests (possibly automated later with phpundercontrol) in less than a week's time. This doesn't feel too bad, all in all.

I did run in to a aproblem' (well, for me anyway) in that the client's Doctrine models are namespaced. Referencing PHP's DateTime object from inside a namespaced class requires it to be referenced as \DateTime().

namespace foo; A class bar { public function demo() { $now = new \DateTime("now"); } }

That was a bit new to me, and I didn't see any specific references to that online, but I may have missed it somewhere. Would have been nice for PHP to drop up to a global scope, or understand references to its own built-in objects, rather than having to do this workaround.

Note: for some reason, an earlier posted tagged abusiness' made it in to planet-php's feed. It should only be pulling aPHP' tags. Apologies if it seemed I was spamming the aggregator.