The display shown in Figure 7.10 contains the same docbase record and navigational controls as in Figure 7.1 but requires no server-side assistance.

Figure 7-10. Static version of docbase navigation controls

The strategy here relies on massive precomputation of HTML/JavaScript pages. It also uses HTML frames to coordinate relationships among generated pages.

The frame-based approach confers a slight user-interface advantage over the single-window display of Figure 7.1. There the controls had to appear at the top of the page in order to occupy a constant location on-screen. But top-of-page screen space is a precious commodity, and the controls chew up a lot of it. What really belongs at the top isn’t the controls, arguably, but rather the record’s title. It contains the most salient fields of the docbase and deserves top billing. With a frameset, as shown in Figure 7.10, we can free up the top of the page for this purpose and lock the controls to a constant bottom-of-page location.

The static solution relies on the same kinds of methods we’ve already seen. There’s a per-docbase template, in this case static-navigation-template.htm, and a template processor, in this case a Docbase::Indexer method called buildStatic-Controls( ). Per-record and per-index, it writes a pair of files. The first, a frameset page, marries the raw docbase record to its controls, as in the following code.

<frameset rows=90%,*>
<frame src=../docs/000013.htm>
<frame src=./000013-product.htm>
</frameset>

The second file—in this example, 000013-product.htm—contains the controls generated for a specific record, relative to a specific index. Client-side JavaScript code generated into those controls works the same way it did in the dynamic solution. Figure 7.11 shows how the parts fit together.

Figure 7-11. Schematic view of frame-based static navigation

This solution shifts nearly the whole computational load to compile-time page production. It requires no CGI scripts and indeed no web server—you can run this docbase from a hard disk or CD-ROM. It’s really efficient at runtime too, because we’ve done away with all the runtime lookups. The current state of the sequential index selector, which was computed on the fly from CGI parameters in the dynamic solution, is now hardwired into each controls page. Likewise, the context-sensitive tabbed-index selector, whose link targets were looked up at runtime, is now hardwired into each controls page.

Apparently we can retire the server, keep all desired behaviors, and even optimize away runtime lookups. It sounds too good to be true, and of course it is. We’ve traded a little bit of work at runtime for a massive amount of work at compile time. A 100-record docbase with four indexes will occupy 900 files—100 for the raw records, 400 for the frameset pages, and 400 for the controls pages. That’s not counting another 100 or so for tabbed-index pages the exact number depending on the nature of the tabs for each index and the sparseness of the data.

Is this crazy? Not necessarily. Unix and NT filesystems can handle huge sets of small files pretty well. The Web mirror of the BYTE public newsgroups ran a variant of this frame-oriented navigation system for years, on a Linux server, without any trouble. In an era of dirt-cheap 6GB hard disks, you can probably afford the overhead of large collections of little files.

Even if all these files don’t create a capacity problem, though, they’ll surely bog down the indexer for any good-sized data set. The frame-based approach probably only makes sense when you need to deploy a standalone docbase that requires only a browser for viewing. When you find yourself in situations like that, though, it’s nice to know how to do things more than one way.