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.

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.

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.

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.

If you application relies on parsing one or several config files each time it is bootstrapped it is important that you select a file format that is fast to parse. But you also want to select a config file format that is easy for a human to read and edit. In a recent application I am building I also had the need to write modifications to config files, so I also benchmarked the Zend_Config_Writer components.

He includes both the sample configuration INI file and the benchmarking script he used to measure the results (all configurations were read from external files, even the native PHP option). His results were pretty predictable (with the exception of YAML reading) with the standard INI file coming in second to the native PHP arrays, but having the advantage of being more readable.

One such limitation that I've recently seen is the performance of Zend_Config. This class underpins the mechanism by which developers provide configuration to the application, and all this config is passed around in the form of Zend_Config objects. [...] For the purposes of this article, I'm referring specifically to config INI files, using Zend_Config_Ini to parse. This is a very common format for Zend applications to use - it is familiar to developers and infrastructure support teams - and is the case where the performance issues become apparent

He talks about parsing ini files and the complications that can come with the Zend Framework method of parsing them - conversion to objects via a recursive method, merging data from different sections and the overhead toArray can cause. He shows an alternative that uses array_replace_recursive to handle the parsing and a class version that offers backwards compatibility with the Zend_Config structure. He claims to have seen a sixty percent jump in performance using these methods over the Zend Framework's defaults.

A friend of mine recently had a requirement where she wanted to have two config files loaded into Zend_Application, so that the specific settings for the server were not stored in the version control system. Hence she has two config files: application.ini and local.ini where local.ini is different on each server. The easiest way to approach this problem is to load the two files within index.php, merge them and then pass the merged config file to Zend_Application.

He includes the code to handle the import - pulling in both configuration files with Zend_Config and merging them with a "merge" call and setting their access back with a "setReadOnly".

Thus far, I'd been using a hand-rolled library for this task; however, this library was now fairly dated and didn't take advantage of many of the newer PHP 5.x features and so, I'd been looking for a more modern replacement. Zend_Config seemed to meet my needs, so I played with it a little and then deployed it in a couple of projects. It did everything I needed it to, and was easy to integrate with both framework and non-framework PHP projects. It also has a couple of neat features, such as the ability to merge multiple configurations together.

His "crash course" starts with an example of pulling in the contents of an XML-based configuration file with dialer information (like for a modem). He talks about setting up rules, formatting the results, working with more complex nested data and much, much more. The Zend_Config component allows you to be hugely flexible with how you handle - and translate - the data that comes out of your config files.

The best part of my favorite PHP framework, Zend framework is Zend_Config. With Zend Config you can run you web application with more power full configuration that any one can change your application setting for use. [...] But in most web application you may have many configuration file with special format such as INI, XML or PHP. Also some of configuration is for one part of your application and may you put in special folders.

He includes the code for his class that allows you to start with a base folder and search through it to find ini, xml and php files with configuration information inside. There's also a snippet of code showing how to use it and pull configuration objects from the data it fetches.

I was asked many times how I organize my config files, and my response was always the same, until some time ago when I switched began refactoring the codebase of my blog. [...] Looking at [the advantages of PHP config files], you may ask now why not everbody is using them. Well the problem mostly is that you cannot create extend-sections (when working with Zend_Config for example).

He compares an example of a method that, using a base config file with some "smarts", you can have it automatically pull in certain files and overwrite settings from the array inside. A sample "other config" file is also included, showing the definition of some PHP settings, resources and database information.