I would have to assume that the framework lends itself to a certain areas of using services from sites such as Yahoo and/or Amazon because those companies happen to have PHP people working there. (i.e.: Rasmus -> Yahoo)

I think for a core and initial release it’s a mistake. Worry about the basics and put out eye-candy later. If the main meal isn’t prepared well, who cares about the side-dishes?

Is it just me, or is the documention all messed up? For instance, in the Zend_Db_DataObject docs, the first code example requires the ZActiveRecord class and makes a call to the setDatabaseAdapter function:

require_once('ZActiveRecord/ZActiveRecord.php');
// Create a ZDBAdapter for ZActiveRecordBase.
$db = new ZDBAdapterMySQL(array('host'     => 'localhost',
                                'username' => 'user',
                                'password' => 'password',
                                'database' => 'test'));
ZActiveRecord::setDatabaseAdapter($db);

But no ZActiveRecord file/class exists in the framework. Another example: to create a database object, the documentation provides this code:

require_once 'Zend/Db.php';
$params = array (
    'adapter'  => 'pdoMysql',
    'host'     => '127.0.0.1',
    'username' => 'malory',
    'password' => '******',
    'dbname'   => 'camelot'
);
$db = Zend_Db::factory($params);

But running this will throw an exception, because the correct call to the factory function requires the adapter as the first parameter, like so:

$db = Zend_Db::factory('pdo_Mysql', $params);

Seems like some blarring inconsistencies between the code and the documentation.

remember that they are targetting 5.0.x as the minimal version and so they cannot rely on newer bundle extensions (thats why they do not even rely on pdo).

Wouldn’t say extending Exceptions where total bloat, I think subclassed exceptions should have more detail about the event that cause the exception. And I don’t mean just the class of the exception.

As for the rest of the framework, only really used ZSearch so far, and apart from a few minor issues, it seems todo what it says on the tin. :)

Glanced at the Front Controller/Routing, and doesn’t have any improvements over my own code atm. Though the comments do say its going to be replaced with something more flexible.

Not quite sure why the JSON is there, as been using the extension which I thought was getting incorporated into the core at some point.

Just extending Exceptions is pointless class bloat. You could just as well use an “exception code” scheme for that. But I presume these are just placeholders that will get expanded once they actually know what to put in these exceptions.

The code looks decent. I look specifically at the DB stuff, since thats my main area of expertise. Its alright, but lacks behind in a lot of areas. Even PEAR::DB should be more reliable when trying to attain portability at this point. There is a really wierd, aka stupid, quoteInto() method, which makes no sense what so ever (this is illustrates the obvious: they do not have better coders than other high profile PHP projects). Their query creation class could help in making a few things portable, but essentially mean you are not writing any SQL in which case I would probably prefer using a true ORM to begin with (which they seem to have cut out).

What I find peculiar though is that their main selling points are not bundled with the release or are severely outdated. I am talking about the tests and the documentation. I can see some things being outdated in the documentation but the CS is totaly utterly out of date. This strikes me as really wierd. Do they internally use a different documentation or how can they leave the CS out dated?

So to conclude at this point the API looks coherent, there is a fair share of documentation. But there is nothing there that really impresses me. But then again they still have some work ahead of them. The ezComponents are already a lot futher, but neither the Zend Framework nor ezComponents really have a chance (or intend) to displace PEAR which will beat them on maturity and scope for atleast the next 1-2 years. What comes then? Who knows? I have stated often that I feel that PEAR needs to reorganize to better deal with its success.

my first impression is that I am not impressed. hopefully that will change. for instance, what’s the deal with the hierarchy of Exception classes that do nothing but extend the standard Exception class? what about YAGNI and KISS besides DRY? even the developers seem confused with them….

What is the point of Zend Framework? We already have PEAR/PECL as a php community..