Zend Framework: Looking Good

Like quite a few people I guess, been absorbed by looking at the first release of the new framework.

Originally had been keeping notes on impressions but feel there’s not much point at this time – the first release is “preview” quality and rough edges are a given. Right now it’s only suited to experienced PHP developers wanted to get an idea of what’s coming – wait and avoid frustration.

It could be argued that it’s been released too soon – it fails Marcus’s install me test, at least as far as the controllers are concerned, which is what I guess most people want to see. Unlike Ruby, PHP is a language that many people know well and are more able to form valid opinions about, so the audience is likely to be far more critical and releasing early risks negative review.

That said, I’m personally happy Zend have got something out of the door. Having having sniffed around for a while, I’m also cautiously optimistic.

Building Consensus

The most positive impression I get out of the preview release is that Zend is laying down various conventions for how to “do” libraries and re-usable code in PHP.

You can get an indication by reading Rob Allen’s blogs on the front controller and views (Rob made it to the PHP London Conf BTW) – notice how he’s organising his own namespace on the filesystem and implementing some of the Zend interfaces;

/lib/Akrabat
/lib/Akrabat/Action.php
/lib/Akrabat/Router.php

If you have the above lib directory in your include path, you can load the classes via the Zend::loadClass() method.

This is just suggestive but because Zend has the weight to get the ball moving, can see them being to generate agreement and conventions on how libraries and framework extensions are deployed. If the Zend framework starts show up in linux distributions and is installed by default by hosting companies, there’s a strong incentive to do things the same way.

That in itself would be a huge plus for PHP, encouraging organisation and providing focus to people writing Open Source PHP libraries. Today putting a project together using third party code means either much glue or hacking the source – with the Zend framewark as the central point, we finally start to get some organisation out of the chaos. Add to that that the framework itself is eliminating the need to re-invent certain wheels, like what’s provided by the InputFilter, as well is providing extension points like the custom view helpers or some of the interfaces they’ve included (DI is needed though – more below).

Choice is still an option

If you prepared to accept the Zend framework at the center (and I don’t think there’s really anything harmful in that, other than perhaps an opcode cache being a good idea), there’s plenty of room to distribute your stuff as add-ons to it.

For example, the framework doesn’t implement a template engine as such, your view scripts being straight PHP (I guess this is based on Paul’s experiences with Savant). There’s nothing to prevent Smarty or WACT from distributing their template engines in a form which is “ready to roll” with the Zend Framework, and in fact there are good reasons for doing so – if the Zend Framework gets wide acceptance, being “Zend Framework Compliant” (logo anyone?) will add legitimacy.

Similar goes for eZ components – these could readily be made to fit into the Zend framework, providing a bunch of stuff that the framework doesn’t do and choice on some of the things it does.

Also, looking at the controllers, I get the impression the default design is going to work in a somewhat Rails-like manner – user defined controller classes with class methods corresponding to particular actions / urls. Personally I’m not particularly enamoured with that approach and would rather see something similar to web.py;

class WikiPage extends Resource {
    public function GET() {
        // response to HTTP GET
    }
    
    public function POST() {
        // response to HTTP POST
    }
}

What so far seems to be the case is that I’ll be able to have my cake and eat it – should be possible to construct this kind of API within the current controller design, with a little extending and implementing of existing APIs.

Killer Feature

Right now think the strongest feature it offers is the search facilities (not yet complete / stable though), which is port of the Apache Lucene (Java) project to PHP. Right now there basically isn’t a decent search toolkit, native to PHP (other than building extensions to projects like Xapian). Can already think of a one project that had to roll it’s own.

Again the way the API is designed, it would be possible for projects using the Zend Framework at their core to tap into the search indexing features, thereby allowing users to have a “unified” search across the various applications they use on their site.

Otherwise, although not exactly a feature, it’s really nice to look at code which has clearly be written in a consistent manner and is well documented.

Concerns

Now there’s a bunch of minor issues I could raise (e.g. the Feed API is very cool but what about character encodings?) but won’t at this time, given the preview status.

There are two big things I think are missing though.

First is the unit tests, which weren’t part of the download. I have the sneaking suspicion that may be because there aren’t any unit tests yet (slap me if I’m wrong), considering one or two of the release hiccups that happened. I know there’s pressure to get this framework “out there” but don’t sacrifice the unit tests (unit tests needs to be on this list)! There’s a bug tracker due online soon. An additional (and I’d argue more valuable) source of feedback would be the test results – if users run the tests and deliver them, say, by email along with a little information about their environment (PHP version, OS etc.), you have a very good indication of how solid the framework is – a giant build farm if you will. Otherwise unit tests are essential to building trust with users (developers).

The other one, which is more obscure, is dependency injection, which I’m sold on after Pawel’s talk. Believe Sebastian of the contributors has some experience there. What Pawel convinced me of with the PHP version of picocontainer is that it can be done in a “lightweight” manner for PHP, that won’t eat resources. For the Zend Framework this seems critical if it’s to become the central “integration” point for other projects – rather than specifically loading and instantiating objects, dependency injection would allow components to obtain “services” via the framework, leaving it up to users to decide which implementation they want used.

Bottom Line

The Zend Framework is what PHP’s been badly lacking for a long time. It’s not ready for use productive yet, but it’s current form should give library developers an understanding of how their code can be made to fit with it. From where I stand, it is most definately not a threat and it constitutes the best chance we’re ever going to get to tie many thousands of hours work together into a coherent platform. Take it or leave it.