8.1 AxKit s Architecture


8.1 AxKit's Architecture

AxKit implements a modular design in which several smaller components are combined to create the larger application. Each component type has an associated configuration option that allows the default components to be changed at runtime on a resource-by-resource basis. In practice, this means that AxKit is extremely malleable and extensibleif one or another component does not do exactly what you want for a given situation, you are free to swap in a new component that does, while still taking advantage of the rest of what AxKit has to offer. In fact, AxKit's continued popularity is arguably due, in large part, to the fact that it provides a set of stock components that covers a great many common cases while still giving developers the ability to easily address special requirements without reinventing the wheel. (See Figure 8-1.)


Plug-in modules stand between the user 's request and the bulk of AxKit's processing cycle. They are used primarily to process the incoming request and to set any internal properties that will help AxKit respond appropriately.


Provider modules handle the task of getting the source for the documents and stylesheets that are used to serve a given request. Each resource has a ContentProvider that is responsible for getting the XML content and a StyleProvider that fetches the source of any stylesheets to be applied during processing.


Language modules provide different ways to transform the XML content being served . Often, an AxKit Language module is a thin wrapper around an existing XML processing library. For example, XPathScript is made available to AxKit via Apache::AxKit::Language::XPathScript, while Apache::AxKit::Language:: LibXSLT offers XSLT transformations by creating an interface to the Gnome Project's libxslt library.


ConfigReader modules control how and from where AxKit gets its runtime configuration information.


Caching modules determine how, where, and under what conditions various resources are cached and delivered to the requesting client.

Figure 8-1. AxKit's order of execution

From Figure 8-1, you can see that first, AxKit initializes the ConfigReader class to get the runtime options needed to handle the client's request. Next, any plug-in modules configured for the current resource are loaded and run (in the order returned from the ConfigReader). Following that, the Provider and Cache modules are initialized . If all caching conditions are met, the pretransformed result is sent to the client, and processing ends there. If the resource is not cached (or the cache has expired , or caching is turned off) the Provider class responsible for fetching the source XML content is loaded, as well as the Language modules associated with the transformations to be applied to that content. Each Language module is then called, and transformed content is sent to the client. There are additional levels of detail that we will touch on while examining the component classes individually, but from the highest level, this is how AxKit works.

Before we dive into the details of extending and replacing AxKit's default components, you should be sure to have a basic understanding of Perl and its capabilities as an object-oriented language. Specifically, you should feel comfortable creating new Perl modules, especially those that are inherited subclasses of other existing modules, and the techniques for installing those modules into places where the Perl interpreter can find them. Of course, since AxKit is implemented on top of mod_perl , the more you know about that uniquely powerful and flexible environment, the more creative and productive you are likely to be from the very start.

The Apache configuration directives shown in each of the following sections to demonstrate how to swap in a new component type presume that the default Config- Reader component is being used. Obviously, if you implement a different way for AxKit to get its configuration data, you need to use your own custom interface to set these options.

XML Publishing with AxKit
XML Publishing with Axkit
ISBN: 0596002165
EAN: 2147483647
Year: 2003
Pages: 109
Authors: Kip Hampton

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net