XML Publishing with AxKit

Custom Plug-ins

Referring to the order of execution introduced earlier, you can see that plug-ins are the first AxKit components to run after the ConfigReader is created. This makes a plug-in the most logical place to put custom code that alters AxKit’s processing behavior based on data from the user’s request. In fact, the StyleChooser and MediaChooser modules that ship with AxKit are really only plug-ins with conventional names that hope to provide a clue about their intended use.

If the default ConfigReader class is used, plug-ins are added via the AxAddPlugin directive. Plug-ins are run in the order that they appear in the configuration file:

AxAddPlugin Apache::AxKit::Plugin::Passthru

# Allow Cookie-based style selection the 'forums' directory
<Directory forums>
  AxAddPlugin Apache::AxKit::StyleChooser::Cookie
</Directory>

# Reset the plug-ins list and add a new set for a particular application
<LocationMatch /about/contact>
  AxResetPlugins
  AxAddPlugin MyApp::Plugin
</LocationMatch>

Plug-in API

All AxKit plug-in modules must implement one function, handler( ), which is passed an Apache::Request instance for the current client request as its sole argument. Access to this request object gives plug-ins the same power to examine and alter the incoming request as a standard mod_perl content handler. Most often, though, they are used to set one or both of the preferred_style or preferred_media properties in the request object’s pnotes table that AxKit uses later to determine which styles ...