Buy:Nexium.Arimidex.Mega Hoodia.Zyban.Synthroid.Lumigan.Petcam (Metacam) Oral Suspension.Retin-A.Human Growth Hormone.Accutane.Prevacid.Valtrex.Prednisolone.100% Pure Okinawan Coral Calcium.Zovirax.Actos….

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.

,Wil