In the post Scaling Silex applications I wanted to organize a one Silex application. In one comment Igor Wiedler recommended us to use RouteCollections instead of define the routes with a Symfony's Dependency Injection Container. Because of that I started to hack a little bit about it and here I show you my outcomes:

He includes example code for creating the application, setting up the main "routes.yml" file with some defaults and two other files for routes in other parts of the site - "api" and "blog". Then he makes the controllers related to these three sections with basic actions catching each of the routes. The source for the entire thing is over on github.

My idea is to store this information within a Service Container (we will use Symfony's DIC). For example here we can [define] our routes.yml. [...] We need to implement one Extension for the alias "routes". We only will implement the needed functions for YAML files in this example.

He includes the code for the extension ("SilexRouteExtension") that can be used to parse the "routes.yml" file to inject the custom routing into your application. This includes the pattern to match, the controller to route it to and the target method. You can also set some requirements like the request method (in this case "GET").

Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail's case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of "buried" code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby's dark magic, e.g. eval(), include(), require_once(), system() and, let's not forget, unserialize().

He talks about how, if you're not careful with the code (third party libraries) that you use in your applications - or don't adhere to good security practices in your own - you could be vulnerable to a similar style of attack. After some investigation on his part, he discovered an issue related to this in the Symfony2 YAML parser (now fixed with a new release).

To summarise… Pay attention to competing applications or frameworks - their problems may also be your problems. If you're worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters' might originate from.

Test fixtures, configuration files, and log files all need to be both human and machine readable. YAML (YAML Ain't Markup Language) is a less-verbose data serialization format than XML and has become a popular format among software developers mainly because it is human-readable. YAML files are simply text files that contain data written according to YAML syntax rules and usually have a .yml file extension. In this article, you will learn the basics of YAML and how you can integrate a PHP YAML parser into your projects.

They start with a brief introduction to the YAML syntax by comparing them to the structure of a typical PHP array. They include the YAML output from these examples and how, despite the ease of its use, it shouldn't be considered a replacement for something like XML (they both have their strengths). He points out some of the current YAML parsing libraries and how to integrate them into your app (he uses the Symfony option).

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.

In this past article I've discussed the dependency injection features when using annotations. This time, we'll see how to use the xml and yaml drivers to do the same (setter and constructor injection). If you don't know how to configure the xml and yaml drivers, please start by reading this.

He describes the different injection methods available with the container - setter injection, constructor injection and method injection. Example configuration content is included - both the XML and YAML versions.

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.