On PHPMaster.com today there's a new post for all the Zend Framework (v1) users out there. In it, Aurelio De Rosa shows you how to set custom error messages for elements in a Zend_Form.

In this article I'll show the solution to a common problem which arises when a developer has to create a non-English website or application that is based on the Zend Framework. How do we mark a field of a Zend_Form which is a Zend_Form_Element as invalid, showing one or more custom error messages? The problem is mainly caused by the native counter-intuitive methods of the Zend_Form_Element class which I'll explain in more details.

He's included a basic example showing the creation of a form and the setup of a text element and some validators to match. He makes a controller and view to handle the output and submission then shows how to use "setErrors" (and "setErrorMessages") of the Zend_Form elements to setup that custom error. This only lets you set one message, though, regardless of the point of failure. To stop things when there's an error, you have to set the "breakChainOnFailure" parameter on the validator to false - then the message will make more sense.

On his MaltBlue.com site today, Matt Setter has a new post showing you how to use the Zend_Form ViewScript decorator in your Zend Framework-based application's forms.

If you've been using Zend Forms for any length of time, you'll know just how flexible and configurable they are. [...] We can, as I'm quite fond of, use the ViewScript decorator. This allows us to have nearly 100% control of the configuration of the look and feel of our rendered forms.

The ViewScript decorator lets you have full control over the layout of your form, letting you use a view (file) to define the markup for the form and injecting your elements into it. There is an issue with using the form in other modules though - it can't find the view file by default. The solution is to pass in a viewModule when using the form, showing it where it can find the view.

In this new post to the TechPortal, Gavin Corbett introduces you to Zend_Form elements (a part of the Zend Framework, v1) and how to create a custom one.

Creating forms in Zend Framework (ZF) is easy, but creating and managing complex forms can get messy! Using config files is perfectly good if you use standard Zend Form elements; it is quick and easy to setup a form in a few minutes however you will have limited control over how the form is rendered. If you want to display your own custom form element correctly in Zend Framework then some configuration is needed in order to achieve this with a config file.

He includes an example of first creating a basic form with a header and a single field element and validating the results of the submission. Building on that, he shows you how to create a custom "EmailAddress" form element and how to add in a view helper to style the output a bit.

On the MaltBlue blog Matt has posted the latest part of the "Zend_Form with Zend_Config" series, part four looking at using and configuring some form validators.

Welcome to the fourth and final part in the Zend Form Mastery with Zend Config series. Previously we looked at the basic form options, element and form wide prefixes, filters and element options. In this installment, we're going to look at configuring Zend Validators via our XML config. [...] To go in to all of them will take more time than is allowed in the confines of this article. So we're going to work through 5 of the more interesting and likely used ones.

He covers the validation for: email addresses, postal codes, seeing if a record exists in the database, IBAN validation and checking to see if a value is in an array. He gives XML examples for each of these validation methods including the definitions of options and error/feedback messages.

On the MaltBlue.com blog they've posted the latest part of their series on using Zend_Config configuration files to create Zend_Form elements. In this latest article, they show how to set some of the other properties on the elements (like "readonly" or "required").

We've looked at custom form filters and we've looked at the core form configuration. But what about the other form properties? What about: setting an element as readonly, an element as required, ignoring an element and love them or hate them, what about decorators.

He shows how to update the XML file to add these new attributes into the structure and the resulting form. Also included are a few examples of using decorators to configure the look, feel and modify the attributes.

In his previous post to the MaltBlue.com blog Matt introduced the concept of configuration-driven Zend_Form instances. He's back with a second part to the series, enhancing his original examples by covering some of the base-level form configuration settings.

Ok, this should have been part one, but irrespective, here's the second installment in zend form mastery with zend config - core form configuration. As the W3c Form spec says, there are 8 attributes applicable to forms.

These attributes, including "action", "name" and "onsubmit", can all be set easily in the XML-based configuration file. He includes an example of the full XML file to show how they all fit together (updated from part 1). You can see an example of the output here and can grab the source for the example from github.

From MaltBlue.com there's a new post (the first in a series) about mastering Zend_Form. In this first part of the series, they look at creating custom filter paths with the help of the Zend_Config component.

When you're working with Zend Framework, and code in general, you keep your configuration as much out of code as you can - right? Well, if you want to write maintainable and flexible code you do. Well, if you've been working with Zend Framework and Zend Form for more than a little while, you know that it really makes that pretty simple via Zend_Config - well, some of the time.

The article shows introduces you to some of the common configuration settings of Zend_Form and how those can be set in a configuration to make building the forms simpler. They talk about pre-element and form-wide filters in this first part of the series, including some code/configuration examples.

Lee Davis has a recent post to his blog showing how you can combine the Zend_Form component of the Zend Framework with Doctrine to help directly "drive" your forms.

On a few of my previous projects I found myself creating more form classes than I'd like. And after the 30th one I figured there had to be a better way. I quickly realised that most of the elements within these forms shared similarities to the data type I would use on my database definitions. As I was using Doctrine at the time I figured I could not only drive my database from my mapping definitions, but my forms too.

He shows how post gets into more detail about using the project (configuring caching, other config options).

The project can be found here on github.

Odafe Ojenikoh has submitted a post he's written up showing how to create a command line PHP application with the help of the Zend Framework and it's Zend_Form elements.

Over the weekend, I was toying with the idea of interactive cli applications using readline() and Zend Form for validating input. My motivation for using Zend Form or rather Zend Form elements was to exploit the power of features such as labels, validators, filters and the prospect of reusing forms within web application code.

His example code defines a Filter for the form errors (returning them as a string) and a "Cli" class that handles the interaction with the command line. Next up is a class defining the form elements - a prompt for a color name and either of the words "thank" and "you". The Cli class transforms the form elements into prompts on the command line and lets you define validators to check their input.

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".