Summary

The configuration system of Nexista is XML based and is designed to allow for multiple modes (i.e live, development, etc...).

The configuration of the application is determined by 2 files. A master config file and an optional user override file. These files are XML based and is organized into sections (path, datasource in the example) and directives (core,lib,etc..).

I've made a couple of changes to the Nexista configuration format, most notably the modes and domain elements.


    
    
        /home/lotus/nexista/kernel/ 
        /home/lotus/nexista/lib/ 
        /home/lotus/nexista/kernel/xsl/
    

            
        127.0.0.1
        127.0.0.1
        
        mysql
         lotus
        
        root
        
        
    
etc...

SimpleXML

Nexista uses SimpleXML to parse the configuration file(s) and make them accessible to the code. There are a few ways these files can be setup for use.

Personally, I use a base configuration file to start. It can be linked with another configuration file to override certain settings. Furthermore, I customize it at build time using entity definitions, similar to how variables are used in programming languages.

Modes

Modes are for different environments of the same application. An example of this might be a development (dev), testing (test), and production (www) mode. To enable these modes in the configuration file (config.xml):

You can then set host names for these by using the domain element. However, I'm now using the server_name / host as a means for separating out the cached files, so the config for each domain is already separate for me. And instead of using PHP to parse other request headers for changing the mode during runtime, I'm using the webserver to set the nexista mode for me, based upon method, browser, etc.

Configuration Mode Vectors

When I use the term "vector" there I simply mean a unique characteristic in the state of the system which can be relied upon to purposely vary the configuration settings. For my setup, these vectors commonly include: * Application name * Host name (aka domain or server name) * Request method (post, get, etc.)

Domain


    dev.example.com
    test.example.com
    www.example.com

In my experience, I'm always shifting these around, so I use an entity automatically created at build time to determine and set the domain.

Config Guidelines

The idea behind config.xml is to make it easy to edit, but at the same time not necessary to edit. You can easily change things here, but most of the time you don't have to.

Config Notes

Also, keep in mind that the config.xml can be combined with an application config.xml to override some of your settings. Right now the config.xml is parsed into a private php array at runtime using simple xml, and even though it is really fast, it might make sense to write it into a php file as is done with the sitemap for a small performance boost.

Each section can have an id attribute. This id attribute can be specified during runtime retrieval of a value. For example, in this case we have the datasource id="lotus" which indicates the connection name as found in a query file. One could create other datasources such as lotus-backup and, using the Exception Handler for the database connection, create a fallback system in case of database failure.

Each directive accepts an optional mode. This mode can be specified at build time to compile the application according to the desired mode. For example, certain directives for error handling for a live mode might suppress error displaying while the default (or another mode) might display errors.

The optional user file uses the same format but can be used to override the values in the master file.

When a value is asked for during build time, the search will take place in the following order (if a mode is used):

  • User directive with mode
  • Master directive with mode
  • User directive w/o mode
  • Master directive w/o mode

Reference

This is a reference for the configuration file directives * config * path * core * lib * xsl * datasources * handlers * actions * validators * builders * compile * cache * tmp * logs * build * sitemap * loader * prepend * default * missing * query * datasource * hostname * database * type * username * password * auth * expire * idle * runtime * cache