Configure PHP-applications with XJConf

A PHP-application typically contains a set of configuration variables. These kind of variables could for example be the database, host, username and password for the mysql-datbase to connect to.

If you are not using a PHP-framework or if you're just doing it all on your own and haven't thought about it, it is quite possible that these variables are either stored in the PHP-files, possibly in many files or perhaps in one file and then set as session-variables. You might also have chosen to store some of the configuration variables in the database.

This might work just fine, but there is an option that is better for configuration variables in my opinion and that is to store them in XML-files.

I have in the planning of a future project together with Randolph been playing around with this. I am using a configuration file for global variables like the ones I mentioned above and also considering using xml-files as language-specific files.

Say that you develop an application in swedish and suddenly you start to notice an extreme interest from the germans for some reason. Then you would like it in german as well, right? If you have coded everything very specific for swedish it can be a tedious work copying and translating everything. And once you have done that you are almost hoping the application won't be succesful in another country as well

So a suggestion on how to use these configuration files is to use them as language-specific configuration files. The actual php-file(s) that stands for the logic will be the same for all countries. All that needs to be added is a conditional statement on which language that should be loaded and to create configuration files for that language.

A very good and easy-started way of doing this is to use XJConf.

I will show you briefly here how I have used it so far and also urge you to read a very good tutorial on IBM developerWorks for more information and further on on XJConf's site.

On a php-page which is a form to fill in by visitors there are a number of labels for each text-field or other type of choices to make. These labels together with button values, headings and the window title are things that are language specific. Instead of copying each php-file for each langauge these labels etc. will be dynamic. A check will be made on which language to use and depending on that load the appropriate configuration file.

For each language there are two xml-files needed:
- The configuration file (that contains the data)
- The definitions file (which maps the tags from the configuration file to types)

A short version of these two files could look like this:

config/us/us_proj_conf.xml:

<?xml version='1.0'?> <elements> <windowTitle>The title @ Wohill</windowTitle> <heading>The Heading:</heading> <name>A name:</name> <category>A category label:</category> <categoryOptions> <categoryOption1>Larry</categoryOption1> <categoryOption2>Elvis</categoryOption2> <categoryOption3>Sahara</categoryOption3> </categoryOptions> <status>Status:</status> </elements>

config/us/us_proj_defs.xml:

<defines> <tag name="windowTitle" type="string" /> <tag name="heading" type="string" /> <tag name="name" type="string" /> <tag name="category" type="string" /> <tag name="categoryOptions" type="array"> <tag name="categoryOption1" type="string" /> <tag name="categoryOption2" type="string" /> <tag name="categoryOption3" type="string" /> </tag> <tag name="status" type="string" /> </defines>

The PHP-file will be built up as follows below:

The following declarations and initiations are necessary to load XJConf:

<?php /* Get language dependent variables */ // include XJConf class file include_once '../config/XJConf/XJConfLoader.php'; // load facade XJConfLoader::load('XJConfFacade'); $xml = new XJConfFacade(); // attach definitions to parser $xml->addDefinition('../config/us/us_vacancy_defs.xml'); // parse XML $xml->parse('../config/us/us_vacancy_conf.xml');

And the following will get the values from the configuration files and put in php-variables:

// access database configuration array $windowTitle = $xml->getConfigValue('windowTitle'); $heading = $xml->getConfigValue('heading'); $name = $xml->getConfigValue('name'); $category = $xml->getConfigValue('category'); $categoryOptions = $xml->getConfigValue('categoryOptions'); $status = $xml->getConfigValue('status');

The PHP/HTML for these elements will look like this. Notice that there are no language-specific content:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns='http://www.w3.org/1999/xhtml' xmlns:b='http://www.google.com/2005/gml/b' xmlns:data='http://www.google.com/2005/gml/data' xmlns:expr='http://www.google.com/2005/gml/expr'> <head> <title><?php Print $windowTitle; ?></title> <link rel='stylesheet' type='text/css' href='../css/style.css' /> </head> <body> <h2><?php Print $heading; ?></h2> <table> <tr> <td class="label"><?php Print $name; ?></td> <td><input type="text" name="name" id="name" class="text" /></td> </tr> <tr> <td class="label"><?php Print $category; ?></td> <td> <select name="category" id="category" /> <?php /* Loop through array */ foreach ($categoryOptions as $option) { Print sprintf("<option value=\"%s\">%s</option>", $option, $option); } ?> </select> </td> </tr> <tr> <td class="label"><?php Print $status; ?></td> etc ...

Installation:
It is recommended in several places that XJConf should be installed with PHP5.0 and with the automated PEAR-installer. Now, if you have your environment on a webhotel and you are not able to issue the shell commands you might think you can not use it. Our webhotel for example is such and they have PEAR installed for PHP4. However, I downloaded this package, unzipped it and copied it to the webhotel to a folder and it worked right on. No PEAR-install required that is.

You can find XJConf for Java as well here.

*** UPDATE ***
Frank Kleine, one of the lead developers of XJConf, mentioned very kindly that the idea is to have only one definition file for several configuration files, i.e. languages. The above approach is a "hard-coded" example and can of course be optimized. You can for example create a definition file which is dynamic instead which allows for easier handling of many category options and so on. In the above example I used the approach to have one definition file for each configuration file for the purpose when category options differs between languages. A dynamic solution (where for example the defs file is a php-file populated from a database) would be much better.