Statistics
Last week we launched a new beta of our Swedish TV guide. It used to be based on Zend Framework 1.0 and has now been completely rewritten and upgraded to version 1.6.2. We didn’t seem to have any difficulties moving from 1.5 to 1.6 during development.
The framework is getting better and better even though I probably never will use things like the form builder functionality. One should never say never. But it seems backwards to me and I think it makes it more difficult to produce more advanced user friendly form based applications. Maybe I should force myself to use it a few times so that I can have a better opinion on it. Maybe…
Anyways, I’m more than happy with the first few days.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.


Zend_Form in it’s current state is only good for a really simple forms, you cannot do some more sophisticated things like for example multidimensional array in names, something like form[element][val1] or form[][name] is not possible in it. Also many of it’s features still need some polishing (errors for the form itself, csrf in multi-window mode), etc. But the idea itself (to generate forms from php) is really cool and allows to speed up development a lot.
@Tomek: actually, you can do multidimensional arrays, but we require that you build them semantically — i.e., using sub forms and nested subforms. Additionally, I’ve recently added new decorators for making form-level error reporting easier, as well as simplifying using the ViewScript decorator with forms.
@Danne: I will agree with Tomek that Zend_Form is not really suited for complex forms. If you’ve already got a complex set of elements, with various relations defined in business logic and various requirements for naming due to the models you will be injecting with the submitted data, or if you have some complex rendering needs, Zend_Form likely is a bad fit for you. Zend_Filter_Input may be a better solution for validating your data. Alternately, you may want to use things like the ViewScript decorator to allow creating complex markup, or create a filter that pulls the appropriate data subsets from the form object prior to passing them to the appropriate models.
On the flip side, if you’re creating new functionality, you may want to target Zend_Form for your form design (in terms of how elements are named and/or grouped via sub forms) so that you can have the benefits of RAD as well as the flexibility of final visual layout.
@Matthew: but can I have more than one level of nesting? like for example an element with name: element[element][element]? I tried with subforms but managed to get only one level – is it possible to overcome this somehow? Also, if we are on the topic of Zend_From – I think the more important issue is the one with csrf protection and multiple windows/tabs. The complex forms and multiple nesting are maybe indeed not a job for Zend_Form but having a decent tool to protect from csrf is fairly crucial IMO and in the current state of it it’s almost completely unusable. I did an very ugly hack to overcome this but it’s only a hack – I would prefer to have some decent solution built in in the core.
And one more thing: while the tone of my post might seem a little bit negative I would like to assure you that I appreciate your (and whole Zend Framework team’s) work a lot – you all do a great job there. Thanks!
@Danne: can you reveal anything about the performance of the site? with all the recent talk about the frameworks and if they produce too much overhead or not, it would be nice to have an info from someone who use one on a ’serious’ and already working site
@Danne: can you reveal anything about the performance of the site?
Unfortunately not. The site does not have enough visitors to be able to see any bottlenecks yet. And the performance issues we have identified in our testing does not come from using Zend Framework.
The part of the framework I have most information about in production systems is the Zend_Pdf functionality. And I am very happy with it. In that particular project we do not use the MVC or database functionality in Zend framework. The only really annoying bug we found in Zend_Pdf was the inability to deal with PDF files exported from OpenOffice but it was fixed in 1.5 if I remember correctly.
One of the good things with Zend Framework is that you don’t have to use everything – if you don’t want to.
The graph, how have you generated it? Looking very good.
It is a graph from Google Analytics. I have not generated it.
Great graph – I like the curve.
I too wanted to request that you keep us posted how your website performs when traffic increases.
And RE: Zend_Form, it’s complex, and it’s also incredibly powerful.
I just did a basic form today (only 10 fields, a couple validators, etc.) and it was great to work with it. Sometimes though, all the decorator madness throws me off because even customizing a simple form can be hellish.
I also haven’t had the time to do anything really complex stuff. I was also hoping that Zend_Form would implement something like Spring Web Flow, because that stuff (although not trivial) is a lot of fun to work with.
Things quickly change. As I am planning a new project I decided to actually use Zend_Form for the administration backend which will not be public to anyone. The project will be on free moments only for some time but I’ll write a post about it when I have gained enough experience.
As for performance I think you yourself have a lot of good information in your post about Zend Framework Performance.