Custom ConfigReaders

By default, AxKit gets all its runtime configuration information from a set of extensions to Apache’s standard configuration directives. In fact, whether the task simply required adding a new XSP taglib or setting up a complex processor-to-resource style mapping, all example applications that we have examined throughout this book rely on the fact that the default ConfigReader is being used. This does not have to be the case. Apart from the top level PerlModule directive that loads AxKit in the first place and an AxConfigreader directive that loads the new class responsible for loading the configuration data, AxKit’s setup can be completely uncoupled from the Apache configuration system.

Reasons for implementing a custom ConfigReader vary. For example, the people responsible for setting up style-to-resource mappings (the part of an AxKit configuration that changes most often) may have limited or no access to the Apache configuration files. Here, providing a different way to set up those mappings while avoiding possible risks associated with doling out write access to httpd.conf and .htaccess files (or, worse, forcing developers to nag the webmaster for every change) makes everyone’s life a bit easier. Or, you may decide that an XML-based configuration system such as the sitemaps in Apache Cocoon 2 fits your needs best—all you need to do is implement a ConfigReader that can extract and process the relevant AxKit configuration information from your XML configuration ...

Get XML Publishing with AxKit now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.