The Zend Framework blog has a new post from Matthew Weier O'Phinney focusing on another useful component of the framework, the zend-config component. This component, already in wide use across the framework, allows for flexible configurations to be defined and easily consumed for your use.

Different applications and frameworks have different opinions about how configuration should be created. Some prefer XML, others YAML, some like JSON, others like INI, and some even stick to the JavaProperties format; in Zend Framework, we tend to prefer PHP arrays, as each of the other formats essentially get compiled to PHP arrays eventually anyways.

At heart, though, we like to support developer needs, whatever they may be, and, as such, our zend-config component provides ways of working with a variety of configuration formats.

He walks you through the installation of the component (via Composer) and the dependencies it requires. The post then moves on to the use of the component to get configuration values from a single or multiple files (.php, .ini, .json, etc). It also covers the optional return of the values as objects, making them read-only, including your own configurations and using alternative parsers (like Symfony's YAML component). It ends with a look at some of the configuration options you can give the component including the addition of processors to manipulate values once they're read.

Rob Allen has a quick post to his site continuing his theme of Slim framework-related posts with this new post showing how to use the ZendConfig module with a Slim application.

Sometimes you need more configuration flexibility for your application than a single array. In these situations, I use the ZendConfig component which I install via composer: composer require "zendframework/zend-config". This will install the ZendConfig component, along with its dependency ZendStdlib.

He shows how to use the glob function to have the component load a set of configuration files and the order they'd load in. He also points out that the ZendConfig component supports other formats including YAML and JSON data. He also includes a code example showing how you can load multiple formats at the same time (ex. some .php files and some .yml files with one call).

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.

In this recent post to his blog, Konr Ness has benchmarked the components that the Zend Framework uses to read in different types of configuration files - JSON, native PHP arrays, INI, XML and YAML files.

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.

Matt Knight has a recent post looking at a specific part of the Zend Framework, the Zend_Config component, and how it's overhead can be reduced (and somewhat replaced) using a few lines of PHP 5.3-specific code.

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.

Rob Allen has a new post today showing you how to load in your own local configuration files into a Zend_Application Zend Framework app.

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

On the Zend Developer Zone there's a new tutorial from Vikram Vaswasi about working with the configuration data from your files (in multiple formats like XML and the more traditional INI) with the help of the Zend_Config component of the Zend Framework.

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.