In my last projects I'm using something I think is useful and it's not a common practice in our PHP projects. That's is the usage of a plain PHP's class for the application's configuration. Let me explain it. Normally we use ini file for configuration. [...] There are many standard options. Why I prefer a different one then? I like plain PHP classes because the IDE helps me with autocompletion. The usage is quite simple.

His example uses a standard class to store the configuration values, one that can be loaded into a project and lets you call the configuration values statically. He gives two examples of how this is helpful in a standard IDE with autocompletion.

These libraries were once an integrated part of the Symfony project, but now they represent a separate Symfony project. Because the Symfony Components are standalone PHP classes, you can both use them without the Symfony MVC framework and integrate them very easily in any PHP project. You can install each of the Symfony Components in the same, very simple manner. All you need to do is download the source code (a TAR or a ZIP archive) from the project page.

The tutorial goes through each tool, briefly explaining what the technology is that's involved and provides some code examples to show you its use.

YAML can be used to describe both simple and complex data structures. It's an easy to learn language that describes data. As PHP, it has a syntax for simple types like strings, booleans, floats, integers, arrays, and even more complex ones like objects. Nowadays, YAML is a heavily used format for configuration files, mainly because even non programmers are able to understand and modify YAML files easily.

He spends a little time describing the YAML markup format and shows how to parse it using the Symfony component, how to get it and install it (via svn checkout).

I was talking with someone [...] here at ZendCon and discovered that they were having trouble with migrations in Doctrine. Having gone through the same issues of Doctrine seemingly not being able to figure out your changes and generate migration classes, I thought I'd post the solution here for future reference.

It's four quick steps that'll get Doctrine to automatically generate the differences (deltas) and upgrade your models to reflect these changes.

Some time ago, I have introduced the new "Symfony Components" project. It is a sub-project of Symfony that aims to give more importance to some of the great libraries we have developed for Symfony. [...] Today, I am happy to announce that the Symfony Components now have their dedicated website.

Each of the current components (YAML, Event Dispatcher, Dependency Injection, Template - though the last three are "coming soon") have documentation, info about the API, examples of how to install and use it and how to give back to the code for the component directly.

Today, with the help of service loaders and dumpers, you will learn how to use XML or YAML to describe your services. The Symfony Dependency Injection component provides helper classes that load services using "loader objects". By default, the component comes with two of them: sfServiceContainerLoaderFileXml to load XML files, and sfServiceContainerLoaderFileYaml to load YAML files.

He reviews the "dumper objects" - tools used to take a service container and push it out into normal PHP code - and how you can use them to dump the Service Container's information out to the XML and YAML formats. Once you have this, it can be loaded back at any time via the two loaders mentioned above. There's plenty of code examples included for these and other more detailed examples.

With the introduction of the XML and YAML configuration files, you might have became a bit sceptic about the performance of the container itself. Even if services are lazy loading, reading a bunch of XML or YAML files on each request and creating objects by using introspection is probably not very efficient in PHP. [...] How can you have the best of both world? That's quite simply. The Symfony Dependency Injection component provides yet another built-in dumper: a PHP dumper.

The dumper lets you convert the service container into regular PHP code (expanding the container's functionality out into a Container class based on the XML/YAML configuration.

I have now just committed YAML data sets to the Database Extension for PHPUnit. So now all those that love the simplicity and straightforwardness of YAML can use it with your data sets. I have also created a persistor for YAML datasets so you can easily convert existing data sets or database data into YAML representations.

He includes an example of a bit of YAML markup and one of the major hurdles he had to overcome - trailing line breaks (as shown in the table_2/column 8 in the example). This functionality also includes a persistor that lets you convert things back the other day - current data set to YAML markup. You can find out more about data sets in PHPUnit in this section of the project's manual.

As of today, there is no simple way to validate the syntax of a YAML file in PHP. But with two simple tricks, it takes only a few dozens of lines of code to build a robust validator capable of checking the syntax of any YAML file against a given schema.

He points out that Ruby has a tool for this (kwalify) but PHP doesn't. He creates his own with the help of the sfYaml component from the symfony framework, translating the YAML data into something PHP can parse more easily - XML. He passes this through an XSL parser and uses the DOM XML schemaValidate function to check it against the given schema.

Here is a short tutorial about my discovery of the new YAML parsing library that comes with symfony 1.1. As you may know, YAML files are a place symfony developers spend time writing configuration, it is very important they have a good tool to manipulate data and debug files.

They include code showing how to pull in a sample file, access the properties inside of it and how to take a multi-dimensional PHP array and push it back out (automagically) into a new YAML formatted file.