A step back?
Like most of you know I’ve been interviewing with a few companies lately and during one of the interviews the interviewer expressed something to me that i thought I was the only one thinking. My thought, “wow i totally know what you mean…but i shouldn’t agree with you because you might think im kissing your ass to get the job”. We were talking about the Zend_Form library of the Zend framework.
The Zend_Form component allows developers to use helpers to create forms. This is much like the form helpers for Ruby on Rails. It has a selector helper, password helper and all the form types that someone might eventually use in a form. With all these positive tools what on earth might be my grip with the Zend_Form? Easy, html/xhtml shouldn’t be handled why a backend developer. With this component we basically take a step back from keeping html/designers away from the backend and backend developers away from taking on another responsibility, creating dynamic forms.
Smarty, Savant, and the basic mvc pattern was set up to facilitate the need to keep such separations intact. HTML coders wouldn’t want to deal with PHP code, so nice looking template libraries such as Smarty and Savant were created to hide these tags from HTML. Now with the introduction of Zend_Form, this idea goes out the window. I’m not implying that Zend_Form isnt a good thing, but is it a necessary component? As developers, we have already crossed this delimma in the architect web road. The outcome? We realized that separation is best.
Could the Zend_Form library have been created to compete with Ruby on Rails?
Armando Padilla
This problem isn’t isolated to Zend Framework. In fact, when I was using JSF, it was even more painful since most component markup had to be compiled in to Java classes. But I do think there are ways to keep separation of concerns intact using Zend_Form. But let me bring in the best person in the world to answer this question.
,Wil
Caveat: I’m the author of Zend_Form and a Software Architect with Zend Framework.
One of the primary goals of Zend_Form was to provide rendering capabilities. The rationale was that with the current view helpers, creating forms was still a tedious process — you had to check for values, check for errors, etc. Without the rendering capabilities, Zend_Form would simply be… Zend_Filter_Input. Developers wanted something that would make their lives easier.
Zend_Form utilizes decorators in its design. These allow you to layer the rendering capabilities. They *can* emit XHTML, but they do not need to — for instance, you could also create ncurses or GTK forms if you wanted. They *can* utilize Zend_View, but they do not have to.
Now, all that said, I completely understand where you’re coming from. Proper MVC says that we shouldn’t have the business logic and display mixed together. However, from a developer stand point, it’s much easier to have everyting related to an element or form in one place, as the form is usually an entity in and of itself.
It’s actually possible with Zend_Form to create something very similar to what Rails has. Because all the information for an element is encapsulated in it, you can very easily use a ViewScript decorator with the form object in order to do the form layout — rendering individual elements at a time, or even creating the full markup for an element by pulling its metadata within the view. This flexibility was provided to appease those who, like you, either want complete separation of the display logic or want complete control over the display logic.
Please don’t dismiss Zend_Form as a step back — examine it a bit more and play with it, and see what things it makes easier. I personally would rather work with Zend_Form at this point than with my hand-coded forms in view scripts.