XML Publishing with AxKit

Chapter 8. Extending AxKit

For many developers, AxKit will be a black box through which they transform and serve XML content. They will neither know nor care about its lower-level components or how things work behind the curtain. That’s fine. After all, one need never know anything about lasers to use a CD player for its intended purpose. If this “I don’t care, so long as it works” approach characterizes your interest in AxKit, you may want to skim the architectural overview presented shortly and skip the gory details that make up the balance of this chapter. If, on the other hand, you are the type of person who takes the “serviceable by authorized technician only” sticker on a CD player as a personal challenge, then this chapter is for you.

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 extensible—if 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 ...