On his blog today Jason Gilmore has a quick post about solving one of his frustrations with Zend_Form (a part of the Zend Framework) - the default form decorators.

It is a fantastically productive framework, one which I happen to use almost every single day. There was however one feature which absolutely drove me crazy. The Zend_Form component's uses the dd, dl, and dt elements as the default form markup decorators, meaning that even a simple contact form consisting of name, email, and message fields and a submit button [is marked up with dl, dt and dds]. [...] It goes without saying that the overwhelming majority of developers do not use these elements to mark up their forms, with the sheer number of questions posted to StackOverflow and elsewhere about getting rid of these decorators backing this assertion.

He gives his simple solution to the issue, something better than removing all of the decorators and using setDecorator to replace them - a simple partial view that echos out the fields directly. The trick is to use the setDecorators call with a "ViewScript" option pointing to your partial and setElementDecorators() call to use a "ViewHelper".

In a new post to his blog today Rob Allen shows you how to create compound form element handling in a Zend Framework application thanks to some custom work with Zend_Form and Zend_View extensions.

A little bit of googling found this site http://codecaine.co.za/posts/compound-elements-with-zend-form which has not unfortunately disappeared, so the code in this article owes a lot of the author of that article. It turns out to be remarkably simple to create a single Zend Form element that is rendered as multiple form elements. We create an element object and a view helper object and we're done.

He shows how to create a custom form date helper that extends the base XHTML to create the isValid/getValue methods for handling the complex date input. There's also the code for the view that creates the custom date input and repopulates the content if there's a need.

On the Ibuildings techPortal today they've posted the latest episode in their DPCRadio podcast series (as recorded at the Dutch PHP Conference 2010) - a talk from Rob Allen about working with Zend_Form (from the Zend Framework).

Zend_Form is a powerful component than can simplify form handling within your web application. Find out in this session how to make Zend_Form render and validate your form elements and ease the pain of forms on web pages.

We will look at configuration, data filters & validation and error handling. One particularly tricky area is the use of the decorator pattern to control the generated HTML when rendering the form. This session will therefore also take a detailed look at this especially powerful functionality and show how to ensure that your forms are rendered as desired.

To listen you can either use the in-page player or you can download the (rather large) mp3 to listen at your leisure. The slides for the talk can be found here.

In a new Zend Framework related post to his blog today Rob Allen takes a look at a different operating mode he found with Zend_Date changing how it handles format specifiers.

I discovered recently that Zend Framework 1's Zend_Date has two operating modes when it comes to format specifiers: iso and php, where iso is the default. When using Zend_Validate_Date in forms, I like to use the php format specifiers as they are what I'm used to and so can easily know what they mean when reviewing code that I wrote months ago.

His example code shows how you can use the standard date formatting strings in a Zend_Form validator (the "php" format) and an example using the Zend_Date::MONTH or Zend_Date::YEAR identifiers (the "iso" format). He also shows how he met two other requirements - validation for empty and a consistent format on the date validation ("Y-m-d").

On the ZendCasts.com site today there's a new screencast posted about using the unit testing functionality that comes with the Zend Framework to unit test your Zend_Form instance.

This screencast will show you how to build a form for changing user passwords with 100% code coverage.

To follow along you can download the source code for this specific example or the entire project to see how it all fits in. If you're interested in other unit testing related topics, see their unit testing section.

On the AjaxRay.com site today there's a new tutorial for the Zend Framework users out there with a library they can use to extend Zend_Form for custom phone number fields.

When taking Phone number as user input, we can worn users about phone number format by setting a hint/description and can validate using Regular Expression. [...] Now, if we try provide this feature in Zend Form, that's possible. We can create three individual Zend_Form_Element_Text objects and join there value together to make the phone number. But, in this case, validating them together is a hassle.

Instead of separate fields, the library they create makes it simple to handle them as a whole field. It works as a helper for Zend_Form and lets you set things like the separator between the text fields, a "format" string and a validator to apply to their fields (in the example code, it's the "digits" validator). Sample code is included to show you how it fits in your form.

Rob Zienert has a new post to his blog today looking at Zend_Form decorators and composite elements to make for more powerful forms in your Zend Framework application.

Today had quite a number of Zend_Form-related questions in #zftalk. Everything from Decorators to Composite Elements, you know - the usual Zend_Form questions. What better way to answering questions than with a blog post and some sample code?

His illustration of decorators shows how to put each of the form elements inside of a "DI" tag to help makes the lives of the frontend developers that much simpler. For the composite elements he shows how to use them to group a set of selects into one object that is then validated through Zend_Date for valid date information. You can grab the code for each of these illustrations from this account on Github

Robert Basic has posted a port of a WordPress plugin that helps you easily make a "honeypot" in your Zend Framework form to help keep the spam bots out.

I just hacked up a little code snippet based on Matthew's Honeypot Wordpress plugin. It's basically just a Validator for a Zend Form element which is hidden from the user via CSS. Cause it's hidden, users won't see it, but spambots will, well, cause they are bots.

The code snippet is included in the post for your cut & pasting pleasure and makes using it as easy as a normal "addElement" call when building your form.

New from ZendCasts.com there's a screencast that will help you ajaxify your Zend_Form instance with the help of jQuery.

We're going to take what was put together in the last 3 videos and now include some server-side validation that will appear asynchronously. This is an example of using Zend_Form as a validation tool via JSON.

Here's the last three videos if you need to catch up:

• Encapsulating Business Rules with Zend_Validate
• Preparing Custom Elements for Zend Validators
• Writing Composite Zend_Form Elements

If you'd like to follow along with this most recent screencast, though, you can download the source directly.

In a recent post to his blog Chris Hartjes has written about his (mis)adventures with Zend_Form, a powerful but sometimes difficult to use component of the Zend Framework.

Zend_Form is a super-powerful, force-of-nature tool. By force-of-nature I mean it does all this crazy stuff, and you can see it doing it, but I am not alone in admitting that taming it sometimes is very difficult. When building tools to make form programatically you either severely limit peoples options or make it so flexible that there are multiple ways to get something done.

Because the Zend Framework "treats you like an adult" it can be difficult to get just what you want from it (ease of use isn't quite top of the list). In this case, Chris wanted a relatively simple form that did some checking before it successfully submitted. Over and over the form passed without him being able to tell why - the solution was a pretty simple one, though - be sure to create all form elements before you do validation.

He includes some same code - a "before" and "after" for the solution.