Page 1 of 1

Concerns with the Zend Framework

Posted: Tue Apr 10, 2007 10:13 pm
by bpopp
I recently changed jobs and left my custom PHP web framework behind. :( As opposed to starting over and rewriting it entirely, I've spent the last few weeks researching other frameworks across many different langages. I've looked at Grails (Java), C# and .net (great language-- horrible framework), RoR, dozens of PHP frameworks including Cake, Symfony, Seagull, CodeIgnitor, ZF, and many others. They all seem to be pretty similar, but so far I just haven't one that seemed to have the right balance of flexibility, power, and maturity.

I've been using ZF for a few days now and think that it's got the most potential, but at the same time, I really dislike some of the core functionality. For example, by the time you do anything constructive with a Zend view, you end up with a complete and total mess. It's like some sick, deformed bastard offspring of PHP and HTML and it defeats the whole purpose of breaking out your view, IMHO. Like many people, I ended up ripping out the view stuff entirely and replacing it with Smarty (which is actually pretty nice). Then I started working with the database classes and quickly realized that its relational ORM support is severely lacking.

I realize that its still pre-release, but ZF has been around for quite a while. It seems to me that ORM would be a more important core library than.. oh.. say.. Amazon and Yahoo service clients. 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.

So I guess I'm just curious what other people think that have been following the project longer than I have. Is ZF 1.0 going to be usable in production? How stable is it at this point (do updates break apps?) Is the core still fundamentally evolving or are these core classes (db/view/controller) about where they are intended to be? All comments are welcome!

Posted: Tue Apr 10, 2007 10:58 pm
by Christopher
It sounds like your opinion is pretty much in line with everyone else who has used ZF here. There is a recent thread that covers some of people's opinions about ZF here:

viewtopic.php?t=65699
viewtopic.php?t=65715

And an more recent thread where we are (painfully so far) trying to hash through the issues of making ZF work for us. That may entail rebuilding classes like the Controllers and View from the interface up. That thread is here:

viewtopic.php?t=66007

There are those who have currently given up on ZF, and some other of us who see ZF as inevitable and are trying to stay engaged. An extra brain helping would be appreciated. :)

Re: Concerns with the Zend Framework

Posted: Tue Apr 10, 2007 11:46 pm
by John Cartwright
bpopp wrote: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 wouldn't consider it overriding the core modules per say, instead extending the functionality to suit the need of the developer. Its flexible enough to do the job on its own, however if something needs extending it is very simple to so.

Re: Concerns with the Zend Framework

Posted: Wed Apr 11, 2007 1:13 am
by Christopher
Jcart wrote:I wouldn't consider it overriding the core modules per say, instead extending the functionality to suit the need of the developer. Its flexible enough to do the job on its own, however if something needs extending it is very simple to so.
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.

Posted: Wed Apr 11, 2007 4:11 am
by Maugrim_The_Reaper
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.8) 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....