Trying to record @akrabat‘s talk about zend_form but didn’t get good camera placement. Won’t be able to put up the video I do have until after Amsterdam. Will need to get a voice recorder instead.
Filters are destructive. This is important to know that. Validators only reject data. Decorators are used for form rendering. Apparently I’m not the only one confused by it because Rob Allen said we’ll go over that extensively. Zend_Form decorators are a combination of Decorator and Strategy Pattern.
Creating form is as easy as extending the form and sticking things in init(). Form elements implements the fluid interfaces so you can chain methods. When creating an enlement, the name you pass into the constructor will become the name of the element. Validators can be added with the string name or the class itself. After making the element, don’t forget to add it to the form. Caveat on Submit, setLabel() will change the value. Be sure to setIgnore() to true because you won’t care about the value of the button. This is a new hint/trick that I had missed in the past. This is helpful.
Now we’re going over an action code example. Basic stuff you can find from the manual on the Zend Framework site. View examples from the site as well. You can echo out the form only or by element in your view. “Under no circumstances display the email address validator to your customer.” How do you fix it? “Translate” the errors. Create a translate object. Set the translator to the form via the form’s setTranslator() method. If you have a lot of forms, you can use the static setDefaultTranslator() method.
On to the meat of the talk (in my opinion), Decoration. =D
Default element decorators
Order is very important. They render inside out. Even though the label is last, it prepends itself before the element. When things don’t go correctly, it’s ALWAYS because you fucked up the order. Adding a required asterick can be set by retrieving the decorator via getDecorator() and set the option requiredSuffix.
Using LI Instead is clearing the decorators then adding the new ones. You render the label then the html tag decorators. That’s the difference. is the last 2 in the above list is flipped. (I’ll try to add code examples later or a link to the slides if they’re available.)
On to form decorators.
Default Form Decorators
Once you understand how things work, they’re relatively consistent. Again, for lists, clear the decorators in the init and add them with your tag using ul.
Going over custom elements. Demo is a YesNo element to set radio multiOptions. Setting the separator on this element with a space will get rid of the <br/> tag that is rendered by default. A ThumbsUp decorator is being used as an example to overriding the render. One interesting I just learned is if there are messages present, that is because a validation failed. That makes sense and can be used for finding out if there are errors.
While it seems like it is complex to do via the object when you could do HTML, the validators and filtering are really great for getting good data. This is what makes most of the ‘work’ with Zend_Form worthwhile. Really great talk, being here for this talk justifies my trip out here. I’m hoping all the other sessions level out the conference price tag as well. In 1 hour, I finally understand Zend_Form decorators which I’ve spent countless hours trying to understand. The key is the order of the decorators set and the slide examples on how they render was really helpful and I look forward to if they become available for posting. I’ll have to ask if they’re available later this year.
Part of the questions lead into SubForm which isn’t discussed here. SubForm is useful for multi-page forms. One difference is in the decorators because you only need 1 <form> tag for your form. Also, I think the naming changes if I recall correctly. You can an element named person[name]. I know SubForm is part of the solution to get that naming convention because I’ve used it in a project but would have to look at my source to give a clear example on how to do it.