Section 3.6.  AxKit

Table of Contents

3.6. AxKit

Although we include it in our list of templating systems, AxKit (http://www.axkit.org) is a slightly different kettle of fish from the modules we've seen so far; this is no mere templating system, it's a fully fledged XML application server for Apache. The most common use of AxKit is to transform XML to HTML on-the-fly for delivery over the web.

However, thanks to XSP (Extensible Server Pages), developed by the Apache Cocoon project, AxKit can be used as an extraordinarily extensible templating system. The basic idea behind XSP is that certain XML tags trigger the execution of given Perl routines. At a very basic level, you can use tags to delimit raw Perl code:

    if ((localtime)[2] >= 12) {

    else {

Notice that AxKit is quite happy for you to intersperse XML marked-up data with your Perl code. Because AxKit parses the XML, it knows that <i>Afternoon</i> is data, not Perl code, and treats it appropriately. This also means that if you have an XML guru handy, he can find a way of validating your HTML-with-embedded-XSP. In fact, since AxKit parses everything as XML, your HTML must be well-formed and valid or you won't get anything out of AxKit at all.

However, AxKit does not stop at this basic level; XSP allows you to create tag libraries with frontend Perl code. For instance, the AxKit::XSP::ESQL taglib provides a wrapper around the DBI libraries. These tag libraries define their own XML namespaces and place tags inside them. So your XML would use a namespace declaration to import the tag library:


and this would allow you to use <esql:...> tags in your page:

          select description, url, title from feeds
               <xsp:attribute name="href">
                   <esql:get-string column="url"/>
               <esql:get-string column="name"/>
              </a> - <esql-get-string column="description"/>

        <esql:no-results> <p> Couldn't get any results! </p> </esql:no-results>

This executes the SQL query near the top of the XML and turns it into an HTML list. The only potentially non-obvious part is where we use <xsp:attribute>. The key to understanding this is that a document processed by AxKit has to be 100% valid, well-formed XML. On the other hand, with HTML::Template and HTML::Mason we could get away with things like <a href="<TMPL_VAR URL>"> or <a href="<% $url |n%>">in a sense, putting tags inside tags.

But with AxKit, the whole document is parsed as XML, and then transformations are applied. With the above examples, AxKit would parse the tag as having the perfectly valid (but nonsensical) attribute values <TMPL_VAR URL> and <% $url|n> and do no more processing on them. Worse still, we can't get away with anything like <a href=<esql:get-string column="url"/>> as that's not even well-formed XML.

So we play a slight trick. We ask the XSP layer to rewrite the <a> tag, after everything has been parsed, with the appropriate HRef attribute. This keeps everything well-formed and parsable.

There are many other tag libraries that perform the same function as Template Toolkit's plugins and give the XML author access to high-level Perl functionality; my own AxKit::XSP::ObjectTaglib allows the programmer to easily wrap any object-oriented module into a tag library.

We're not going to implement our RSS aggregator in AxKit, as it turns out, because AxKit is a fully featured XML processor. All of the heavy lifting can be done in XSLT stylesheets, and there's almost no Perl content involved.

Instead, for more on AxKit, we'll refer you to Perl and XML(O'Reilly) and http://www.axkit.org, the AxKit home page.

    Table of Contents
    © 2000- NIV