It’s time to shift gears, roll up our sleeves, and start building docbases. Our first example will be a web docbase that works like the BYTE Virtual Press Room did. In this chapter, we’ll look at ways to capture and store docbase records. In Chapter 7, we’ll explore how to generate sets of pages that enable users to navigate a docbase. By the end of the two chapters, we’ll have created a system that you can use to manage monthly status reports, service bulletins, analyst reports, or any template-driven, semistructured documents.

What I’ll call the Docbase system includes a family of Perl modules. Docbase::Input, featured in this chapter, collects, validates, previews, and stores docbase records. Docbase::Indexer and Docbase::Navigate, which we’ll encounter in Chapter 7, support indexing and navigation of docbase records. These modules are driven by other Perl scripts, some general and some tailored to each instance of the Docbase system. Also associated with each instance are templates that govern the form used to collect its records and define the repository format used to store the records. Finally, each instance uses a standardized directory structure.

Is the Docbase system something you can apply directly with little modification, or is it just a way of illustrating techniques that you’ll need to adapt heavily to your purposes? Both. With minor adaptations, mostly involving templates, you can use it to create a variety of docbases that gather, organize, and present sets of semistructured records. In this sense, the Docbase system is reusable.

On another level, what’s reusable are the ideas and techniques it embodies. The pattern is: XML storage, mapped to Perl data structures, managed by Perl modules, delivered as HTML pages or SMTP/NNTP messages. We’ll see variations on this theme throughout this book, solving lots of different kinds of development problems. In this sense, the Docbase system is intended to serve as an extended example of a way of problem solving that I find almost infinitely fruitful.