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
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
.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 ...