Framework blues…
September 12, 2008
I perhaps have to watch my words a bit, because I’m going to start doing remote training for Zend in the next few weeks. Having said that…
I started trying to use Zend Framework the last week for a project. I’d started it in Grails for rapid prototyping, but there’s no hosting option for Grails that will fit the client needs, so I then looked at Symfony. I found that to be a bit overkill - it was harder for me to picture how this app would fit in.
So, I took a look at Zend Framework. The first few hours were nicer than I remembered. I’d used ZF pre 1.0 and again at 1.0 again, and there just wasn’t enough there to convince me to use it. Watching some of the Magento issues the last year or so convinced me I’d made the right decision to let ZF mature some more.
And then I hit something else this morning that made me slap my head again and say “what the heck? does anyone actually use this for real projects?” Now, you may think what I’m about to describe is ‘petty’ or ’stupid’ or whatever, but imo it’s indicative of framework authors’ lack of understanding of real world needs (not specifically ZF).
$formField = new Zend_Form_Element_Hidden(”type”);
$formField->setValue($type);
$form->addElement($formField);
When $form->render() is run, the hidden fields are rendered with the same <dd> and <dt> tags around them. This competely hoses up spacing - this creates extra empty spaces on the screen that I don’t want. HIDDEN means DO NOT DISPLAY. Yet the defaults for Zend’s Form system do not respect what I *want* to happen.
Could I store the data in a session instead of a hidden field? Sure. Could I write some sort of ‘view helper’ or ‘plugin’ or whatever to get around this? Probably. But should I have to?
Again, this is just an example of something I found that bugs/annoys me, and it happened to be ZF. This is something I’d have expected in a pre 1.0 release, not something that is regarded as a leading PHP framework with more than 2 years of development, and more than a year of post 1.0 behind it. When I hit these sorts of issues I really have to wonder how many major PHP framework authors actually do day to day development?
All that said, I mentioned my first few hours of using ZF were more pleasant than I expected. I was able to get some things done faster than I expected, but not necessarily faster than using any other framework (that I’ve used over the years).
Did you like this post? Buy me a hot chocolate!
Posted in 
September 12th, 2008 at 8:44 am
Went to go add this as a JIRA issue. It already exists:
http://framework.zend.com/issues/browse/ZF-2718
The rationale is something about XHTML correctness/validity.
September 12th, 2008 at 9:39 am
It doesn’t sound petty, it is disappointing when the frameworks come back with things that are unexpected.
September 12th, 2008 at 9:46 am
Though it does nothing with forms,
you might want to have a look at eZComponents (ezcomponents.org) if you are looking for a framework.
They actually are more a library than a framework, but from my point of view, their philosophy makes much more sense than any framework.
September 12th, 2008 at 9:50 am
That is quite annoying really. Perhaps they should be grouped at the end still.
Or given a css class name like .zend_hidden - so you can hide it in your CSS easily.
September 12th, 2008 at 10:00 am
@christian - that’s ZF’s philosophy too though - “no one way enforced” (more like a library - pick and choose) - I actually prefer more structure and defined ways of doing things. Thanks for the tip though - haven’t looked at EZ in 2-3 years.
@dougal - yeah, that’s possibly an option. The annoying thing is that it doesn’t come predefined with anything. If there was a default view/template with a default CSS, having the ZF form stuff rely on those would be extra useful.
As it is, I get dt/dd tags with no styling, so I need to style them myself. Given that the dt/dd tags have no IDs in them, I wouldn’t be able to style/move them based on the form element names anyway, so the default thing I’m doing (as I suspect most people do) is to line them up left/right top->down, just like what a TABLE would do. I’d prefer if the default Zend_Form stuff used a table for layout, which would make default usage look normal without so much styling effort. For those who have some sort of irrational beef with table tags they could use another Zend_Form subclass (Zend_Form_DDDT maybe?)
September 12th, 2008 at 10:11 am
really you should contact Matthew Weier O’Phinney whom I think its the original author of that particular library; I’m 100% sure he has real world usage of it and can probably address it simply, with a solution that come down to decorators. Granted, it might be more coding then you would expect, but that is how its done in this framework.
back to the whole xhtml validation thing, I would like to know who are the people writing these DTDs, do they actually create websites on a day to day basis? they sure like to take out useful ways of doing things with code, only to replace them with more cumbersome ways, most of which I get _ZERO_ benefit from other then I can say it validates.
grr.
September 12th, 2008 at 10:14 am
Good point on DTD writers. I understand the argument for academic purity in libary writers wanting to adhere to ’standards’. However, at some point, if pretty much everyone does something one way, and the academic ’standard’ is something else, who’s ‘right’?
The JIRA issue above shows that Matthew is aware of the issue, and there may be a ‘fix’ at some point.
September 12th, 2008 at 10:53 am
Yes, I’m definitely well aware of the issue.
The reason the DtDdWrapper is used on the hidden elements is so that they don’t get an invalid semantic relationship with another element. That said, if you don’t care about that, you can easily change the decorators:
– and be done with it (this can also be done via configuration settings.
The better solution is to remove hidden elements from the general form content body and push them to the end. This will require a bit more work as Zend_Form is unaware of the element types. We will achieve this with decorators, but development of it has been pushed back by other initiatives (testing, Dojo integration, etc). While I understand your frustration, the fact of the matter is that there are solutions already, such as the one I noted above.