Every implementation of ZF that I've seen has rewritten huge chunks of the core functionality. Astrum Futura, for example, looks like it's replaced both the model and the view functionality. On one hand, it's impressive that these core modules can be replaced so easily, but on another, it's discouraging that its so fundamentally necessary at this point. Worse, once you've ripped out or overridden all these core modules, what's going to happen when you start trying to incorporate updates to the ZF framework.
I am the Astrum Futura author

- it is a cool setup to trial the ZF in a non-essential app. It's important to note (besides AF being out of date from 0.

that I haven't replaced many ZF classes. Rather I've done a certain amount of subclassing to tweak behaviour. For example, Astrum_View extends Zend_View to add two View features. 1) to lock sessions, and 2) to automatically escape View variables by default (many developers, to be honest, are crap at doing things like that manually). I subclassed other things - some are even now defunct since 0.8-0.9 got around to doing something similar.
I will agree I found Zend_Db to be a horrid mess - I simply find it too complex for its own good. Complexity breeds errors, and Zend_Db has run through a lot of issues in the issue tracker. Unit testing hasn't been used to it's full advantage here but that's not unusual in PHP. Once the current Zend_Db iteration is sorted out (bear in mind they overhauled it only recently) we'll see an ORM layer get proposed. Until then Astrum Futura uses a small Data Objects library which is good enough for a small application relying on PDO with a small subset of ORM needs.
On a positive note - public pressure and unit testing ensures the ZF is inherently flexible. Also the ZF has a shallow class hierarchy which makes most of the components useable in isolation. That alone makes knowing the ZF a pretty useful tool for your developer toolbox - it's like having a high-quality PHP5 PEAR repository (though not as expansive), not just a huge monolithic "framework". This is one area it differs in from Symfony - Symfony uses pre-existing libraries a lot. The ZF reinvents the wheel for everything to assure enterprise users of it's IP integrity. It's a strength and a weakness both - but should be beneficial in the longer term.
I know it's very easy to paint a critical picture - but honestly I'm far more critical of things I like, than things I just put up with

. It has its warts, and compared to alternatives it's on the immature side of the fence for now. But it does have more good points than bad - and many of those bad ones will eventually be reduced as the framework matures and more users pile on pressure to make changes. Missing features will get added, etc. Don't give up on it yet - it will be a bit of a journey to see a "complete" version but that day is coming.
In the meantime, if the ZF is seeming too harsh - experiment with the alternatives. Many have a great deal of documentation and have a more honest version number

.
arborint wrote:It is one thing to extend the ZF classes, which is what their plan is. But people are finding that they need to go back to the interfaces and implement complete replacements. I have even seen on the mailing list where they recommend cut-and-pasting from the standard files and building your own custom replacements.
Agree. But the framework has never been formally optimised. AFAIK, pre-1.0 optimisation is regarded as premature. Not quite accurate - stable API status of any sub-component assumes optimisation won't impact design, and therefore shouldn't be premature. I don't think they plan on ignoring optimisation forever - least I hope not.
Until that happens - replacing is not difficult. It's even inevitable in many cases once you're familiar with the interfaces, and you spot those areas where work is being done not needed for your application. You can only subclass so far before the subclass itself is basically replacing all the important stuff....