Configuration Simplification

It’s several times faster than presently, actually, because we don’t load a file, check the existance of another file, hit the database, compute the values for location and URL on the fly, and then hit the DB again to get the user specific settings and merge the two together.

In fact, if we did this correctly, if someone was using caching and turned off statistics, your site could serve pages without even needing to connect to the database.

Currently we only hit the database if the siteCache.idx.php file is not available and (for user settings) once after login and then store the setting inside the sesssion.

So basically you’ll be caching user settings in xml and removing the on-the-fly generation of base_path and base_url, correct?

IMO, If it’s faster than the current then we should go with it.

If we can figure out the multilingual issue that I mentioned above, it also means we can use the config file to generate the preference screens. Then if we need a new preference, the only thing that has to be done is it would need to be added to the XML file. Which, of course, could be done via the config API.

Several cool benefits like that.

Wouldn’t that also mean that users will be able to download our xml config files?

If we can figure out the multilingual issue that I mentioned above, it also means we can use the config file to generate the preference screens.

Why would should we be doing that? IMO the config file should not contain system settings or be used to stucture the preference screens. It should be simple enough for third party applications to include and then get connected to the MODx database.

To my thinking, the security issue is best handled by putting the XML config file in a PHP wrapper.



I’m not great with XML so I don’t know if the <?php ?> tags would throw a parser off or not. If so You could probably throw them in a comment <!-- <?php ?> -->, right?

I see two possible ways to handle the multi-lingual issue. I’d say that the best option to me is to simply keep it within our current system and look for a $_lang element that matches the configuration alias. Example: $_lang[’SITE_START’]. If it’s not found then we could fall back on the english version which could be included in the XML file.

I think this is really a part of an bigger issue. Do we have anythnig in place to allow multi-lingual support for plugins/modules/snippets, etc? I think we should have a sort of a repository where every resource could register the text that it will use so that it can all be collected in one area. We could then make a nice translator interface where it would be easy to go in and make translations. Does that make sense?

The other way would be to keep the language definitions in the XML file and do something like this.



I see value in having the XML the one place that would drive our configurations. The way I see it if we should eliminate interdependencies as much as possible. This is really the heart of the OO theory. Entities should be as self contained as possible. If we define the paramaters in the core and store them somewhere else then we’re creating an unnecessaryinterdependency the way I see it.

In regards to the multi-lingual discussion, I’d prefer to see something that allowed us to use XML files (these could be created for each stand-along resource) to store the default (out-of-the-box) values. These ’resource bundles’ could then be overridden by and/or extended by users storing values in a database table. I worked on a huge J2EE project where we handled the multi-lingual challenges this way (as well as much of the rest of the configuration as well), and this made deploying the highly data-driven applications much more manageable. This will help immensely with upgrades and customizations too, as the data overrides could be maintained even when the core or a specific component included an updated XML resource bundle. Component authors following the same system could provide their own XML resource bundles to be overridden as well.

<?php if(IN_MANAGER_MODE == ’true’) { header(’Content-type:text/xml’); ?>
<?xml version="1.0"?>
...
<?php } ?>

Using the above would mean that third party apps would:

1) have to include an XML parser to parse the config file or include the MODx API to do such
2) they would have to define IN_MANAGER_MODE before the can include such a file

On the issue of language support... It has been discussed within the forums about setting up something like a dictionary object or similar that you can use to load your language files. This means that the database would store the words and their transulations and the system would create cache files based on the section/category to which they apply.

Users could then do something like this:

$modx->dic->setLanguage(’en’);
$modx->dic->loadLanguage(’home_page’);

or

$modx->dic->setLanguage(’fr’);
$modx->dic->loadLanguage(array(’home_page’,’menu-bar’));

You could then use the language just like you normally would

echo $_lang[’welcom_msg’];

IMO these cache files should not be stored as xml files. XML is good but it takes a longer time to be parsed that would a normal php file. Now I could be wrong but from what I’ve seen by using DOMIT Lite it took something like 0.1 secs to parser a file that had only a few elements. Compared to a simple php file such as:

$_lang[’welcome_msg’]=’Welcome to your content manager’;

XML is good but at times it might not be the most efficient solution.

Why am I against using XML? It due to speed. Currently the Etomite parser due to it’s integrated nature is capable of rendering a page within .1 seconds on the fly while it can render cache pages within the .02 range. The MODx parses lags behind it a little due the overhead created by including the API as a separate file. I’ve since made a few changes in a test version of modx to get speeds of up to .019 seconds for cached files. The goal is to be able to crunch out speeds of something like .005 seconds or less.

With that said I could be very wrong but I’ll just wait and see.