Using the configuration cache in a symfony plugin

Posted April 4, 2007

In a plugin that I recently published, the sfSimpleBlogPlugin, I used a new feature of the symfony framework that allows dynamic registration of a configuration handler. Why is this interesting? Because it allows plugin authors to use custom YAML files for the configuration of their plugin, and to take advantage of the configuration cache system to parse this YAML file only once in production.

Let's take an example. Your FooBar plugin can be controlled by a FooBar.yml file located in the application's config/ folder. This YAML file contains parameters for the plugin and is environment dependent:

all:
  lorem: ipsum

dev:
  lorem: dolor

What would be interesting would be to be able to read these parameters from the code, using the sfConfig registry. That's quite simple. In the plugin's config.php (which is executed during each request), write the following code:

$foobar_config_file = sfConfig::get('sf_app_config_dir_name').'/FooBar.yml';
sfConfigCache::getInstance()->registerConfigHandler($foobar_config_file, 'sfDefineEnvironmentConfigConfigHandler', array (
  'prefix' => 'foobar_',
));
include(sfConfigCache::getInstance()->checkConfig($foobar_config_file));


Now, to get the value of the lorem parameter from everywhere in the code, just type:

$lorem = sfConfig::get('foobar_lorem');


The very interest about using a config handler rather than parsing the YAML file directly is that the sfConfigCache::checkConfig() method will process the file and put the processed PHP code in cache. Performancewise, this is the good way to have a custom configuration file controlling a plugin.

As the sfConfigCache::registerConfigHandler() method is only available as of symfony r3703, this will only work with the latest trunk version.

6 Comments so far

  1. Mike Nolan on April 4th, 2007

    Hi François,

    Saw your blog plugin last night and very impressed! Looking forward to seeing how you're going to handle plugins for your plugin and I can think of all sorts of ideas for that already.

    A question about changes in the trunk. What's the process for these getting released? I don't want a date (I know how annoying that is!). I'm guessing these aren't changes for the 1.0 branch but will come in 1.1 (or 2.0!!)?

    Will the fact that 1.0.x will be maintained for a long time affect the speed that new features are rolled out, or should I just bite the bullet and check out a copy of the trunk for my next project? :-)

    Thanks for your hard work!

    Mike

  2. François Zaninotto on April 4th, 2007

    Hi Mike,

    Thanks for the heads up. As for allowing other plugins to play with it, I guess the sfMixer and its callbacks will be of great help.

    The trunk changes don't have a release date yet. We can think of many interesting changes for the 1.1, and there are a number of open tickets, but we don't have much time for now... We'll post updates as soon as we have more visibility.

  3. Mike Nolan on April 4th, 2007

    Trunk it is then :)

    I've done quite a bit of work with WordPress MU recently and they use a typically PHP4 method of adding actions and filters using a global array. It might not be pretty but it certainly makes developing addons very simple.

  4. Jonathan Wage on April 8th, 2007

    I just got sfSimpleBlogPlugin installed on www.jwage.com, it is pretty cool. It is a good example of making a plugin 100% configurable.

    I found a few issues/bugs that I fixed in my copy. How can I get commit access to svn so I can contribute fixes and enhancements to other peoples plugins as I use them?

  5. François Zaninotto on April 10th, 2007

    Jonathan: I suggest you use the symfony bug tracker and open tickets on the "sfSimpleBlogPlugin" component, and attach your patches to it.

  6. Redo The Web » Customizing a plugin schema on September 30th, 2007

    [...] a previous post, I explained how a custom config handler can make this task even [...]

Leave a reply