E.7. More Reasons to Use AxKit
Hopefully this will have whetted your
appetite
to play with AxKit. If you still need convincing, here are some extra
things AxKit can do:
-
AxKit can work with filter-aware modules and, instead of XSP, use
other templating systems (such as Mason) to produce XML structures
that will be styled on the fly after being passed to AxKit.
-
XSLT, XSP, and XPathScript aren't the only possible
processors. You can fairly easily create a new type of processor
(such as a graph-outputting processor that would transform XML into
charts, or rasterize some SVG).
-
Apache configuration isn't the only way to control
AxKit. You can create a ConfigReader that reads
the configuration from another system, such as an XML file on disk.
-
There are ways to choose stylesheets on the fly—for instance,
to allow people to see the site with the design they prefer, based on
cookies or a query string.
-
AxKit has an intelligent and powerful caching system that can be
controlled in various ways or replaced by a custom cache if needed.
-
You don't need to fetch the initial content from the
filesystem. The Provider interface allows you to return data from
wherever Perl can get it (e.g., a content-management system).
For more information, help, support, and community chat, please visit
the web site at http://axkit.org/
and join in the discussions on the mailing lists, where you will find
like minded people building a range of solutions.
| | | E.6. Putting Everything Together | | F. HTTP Status Codes |
Copyright © 2003 O'Reilly & Associates. All rights reserved.
|
|