This weekend I've taken a look at the initial release of the Zend Framework.

The first thing I've noticed is that authors of frameworks can sleep soundly again :-), as the zend framework is not yet a framework (in the wikipedia sense of the word).

Currently, it's more a component library containing all kinds of useful components. This does not have to be a disadvantage though, because this makes it very easy to integrate with other applications and existing frameworks. In fact, there are some components such as the pdf and mail classes that are very useful for certain types of web applications, and it is fairly easy to use them in an application that was built using an existing framework.

People expecting a kind of 'ruby on rails' for php have to wait a little longer though, as the Zend Framework is not there yet.

When diving into some of the classes, there are some decisions that I don't quite understand. For example, have a look at Zend's implementation of isReadable. It is a wrapper for PHP's is_readable, with the addition of also taking the include path into account. Since this is a very useful feature in many occasions, why not enhance PHP's is_readable function with this functionality? Especially since it's just a small enhancement, so in my opinion, it would be better to put this directly in PHP, instead of in wrappers. (the same goes for some of the other framework methods that are wrappers for some existing functionality.) Putting stuff in wrappers is, in my opinion, a bad way of enhancing functionality. Suppose wrapper 1 adds functionality A, and wrapper 2 adds functionality B. If I'm in a situation where I need both A and B, I have to take one of the wrappers and implement the other feature myself. So in the case of 'low level' methods such as this, I'd rather have the functionality in the base function instead of in a thin wrapper.

Another functionality I have some doubts about is the registry. It is advertised as a method to handle singletons. In my opinion, the fact whether a class is a singleton should be handled by the class itself. The application author should normally not need to make the decision whether some class he is using should be a singleton or not. Also, the concept of a singleton's getInstance() method ('give me an instance or create one of there isn't an instance yet') seems to be lost in the zend framework registry, as there is no such method and the application author needs to define his own 'if it's not in the registry yet, add it' logic.

The RSS feed functionality is nice, and would be even nicer if it had methods for creating feeds instead of consuming them. This type of functionality however is typically something that would be useful to have available as a separately downloadable, dedicated library instead of as a standard part of the framework.

The other components all seem useful and nice too. There are definitely components that I'm going to use in applications I'm working on.

Overall, the Zend Framework looks promising. I think that at the current state, the zend framework falls in the category of libraries such as PEAR and ezComponents. All of them provide a wide choice of generic components. I think the stuff that would make it an actual framework are still missing, (but the model/view/controller classes are a step in that direction), but this has the major advantage that frameworks such as Blueshoes and ATK are not actually competition, but potential users of the zend components.