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
directive. Plug-ins are run in the order that they appear in the
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>
All AxKit plug-in modules must implement one function,
), which is passed an
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_media properties in the request
pnotes table that AxKit uses later to determine which styles ...