Zend Framework and YAML config files
YAML has become quite a buzz word in the last few months. For those of you who don't know yet (perhaps because you read my blog, and only my blog!?), YAML is:
YAML(tm) (rhymes with "camel") is a straightforward machine parsable data serialization format designed for human readability and interaction with scripting languages such as Perl and Python. YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering.
YAML is becoming popular for a good reason: It's easy to work with, and lots of fun! If you've tried Symfony, you know it heavily uses YAML for it's configuration files - a task which YAML fits like a charm for.
Being the buzz-word worshipers that we are, several voices have been heard in the the Zend Framework community for a YAML parser class, and most notably, for a
Zend_Config implementation based on
YAML. Pádraic Brady already proposed an implementation for
Zend_Yaml, but for those of you who are impatient (like me!) and want to use YAML as configuration
files in your projects today, here's a simple and elegant solution:
First, you should compile and install Alexey
Zakhlestin's PHP Syck bindings from PECL
(note: it's beta, production use at your own risk!). You'll need the syck library installed, and once you have it, the extension
compiles quite easily. Once you have the Syck extension loaded (check your phpinfo output), you can
easily use the following code to create your own Zend_Config_Yaml class, which parses YAML files and
behaves just like other Zend_Config implementations:
-
<?php
-
-
require_once 'Zend/Config.php';
-
-
class My_Config_Yaml extends Zend_Config
-
{
-
public function __construct($filename, $allowModifications = false)
-
{
-
throw new Zend_Config_Exception('Filename is not set');
-
}
-
throw new Zend_Config_Exception('Syck extension is not loaded');
-
}
-
-
try {
-
} catch (SyckException $e) {
-
throw new Zend_Config_Exception('Unable to parse YAML file: ' . $e->getMessage());
-
}
-
-
parent::__construct($config, $allowModifications);
-
}
-
}
Then, usage is quite easy:
-
// Obviously require all needed classes and properly set your include_path...
-
$config = new My_Config_Yaml('config.yaml');
-
-
/*
-
config.yaml looks like this:
-
dev:
-
db:
-
user: myuser
-
password: secret
-
hostname: localhost
-
dbname: myblog
-
adapter: pdo_mysql
-
*/
-
-
// Access the database configuration
-
$db_user = $config->dev->db->user;
Easy, right?
* If you can't or don't want to install Alexey's PECL extension, you might be able to use Spyc instead, which is a PHP implemented YAML parser class. It'll be much slower (to slow for production if you ask me) and you'll have to change the code as well - but not more than two lines of it as far as I can tell...














Thanks for that!
I don't suppose you have any benchmarks for the syck library versus the Spyc class?
Not yet, but I am sure the difference is quite big. Any data serialization / deserialization procedures I've met so far are far faster and less memory hungry when implemented natively.
If anyone has benchmarks, I'd be happy to see them as well.
Ah, kids nowadays and their fancy YAML config files... If memory serves. we use to do it like this in my day (and we all grew up fine! ;)):
// If namespace is an issue, wrap it in a Config class.
$dev_db = array(
'user' => 'myuser',
'password' => 'secret',
'hostname' => 'localhost'
// etc....
);
When you go the Syck/YAML way, you're adding an unneeded dependency to your code: if the Syck extension or library are found to have some bug, you're screwed. When they release a new version, you need to upgrade and make sure the code still works ok. If you want move your app or reuse the code in an environment where you can't install Syck, you're screwed. If your code grows to an open source app (like MediaWiki or Wordpress) you're losing many potential users with shared hosts. Is it really worth the slight gain in readability?
First of all, you're not that old, grampa
Second - you're right - just for readability, it's not worth the effort. In general I think that until the Syck extension is in the core of PHP (if it will ever be) you shouldn't rely on it. Of course, you can use user-space YAML parsers, but those will always be too slow to be used in real-time IMHO.
On the other hand, you got to love the non-intimidating way YAML looks and how accessible it is for non-programmers. Quoting a smart guy I know (that's you dude), most of the PHP users out there are not even programmers - so config files in YAML are better for them then PHP code (it also reduces the chance of messing something up).
Personally I'd prefer using flat INI files for most tasks - they are easier to parse and less "fragile" than YAML. However if you need complex nested configuration (for whatever reason I can't think of) I think YAML is "friendlier" than XML or PHP code.
BTW, one of the powers of Zend_Config is that it allows you maintain a similar interface for configuration with different configuration file formats - INI, PHP arrays, XML and maybe even YAML.
Well, that brings me to another issue I'd like to rant some about, while I'm in my grumpy old timer mode: What's with PHP's distrust of native-language libraries? I'm not sure at all that PHP-based YAML parsers (or other libraries) will always be too slow for production - Ruby or Python or Perl libs are often written in these languages, and PHP can easily match these for speed.
If we had more libraries in PHP instead of C, the issues I mentioned above wouldn't be critical and our lives would be a lot simpler. (If a little slower. And that's not bad too. What are you youngsters chasing after anyway?)
You are right again - I shouldn't say so deterministically that it will be too slow for production. What can I say? I'm a premature optimizer...
Anyway I've played around with Spyck - the only user-space implemented PHP YAML parser I found at the time - and it's memory consumption for larger files was horrible.
What I should say that this is the kind of task that will be substantially faster if implemented natively - but it will not necessarily be too slow for production if implemented in PHP. How does that sound, grampa?
Nice article. Actually, how do you manage to get this nice looking box around your code?
. I mean really. I have started using pastebin.com, but I would like to have the
formatted code right in my blog. You know what I mean. Peace.
It's actually a Wordpress plugin called iG:Syntax Hilighter or something.
http://blog.igeek.info/wp-plugins/igsyntax-hiliter/