11 Vortex Library Modules

The problem

When creating a complex Vortex application, keeping the code in one large script can be unwieldy as code size increases. For example, our previous security example more than doubles the size of our patent example, even though it's only part of the application. Splitting it into multiple scripts is easier. But that usually means common code - such as look-and-feel or security functions - must be duplicated among the files. And when these functions are changed in one file, all the others must be updated too, which is time-consuming and error-prone. It may be unclear which files need to be updated without searching them for calls of common functions.

Keeping track of revisions is an issue also. One programmer may revise a script, unaware that another is still working on the same section, and stomp the other's changes. A new version might introduce some bug, but without specific backups it's difficult to fall back to a known safe version.

The solution

Library modules help solve these problems. Modules, available in Vortex versions after 2.6.936300000 (Sep. 2 1999), provide the following features to Vortex:

  • Modularity
    Code for an application can be split into logical sections instead of one big file.

  • Code sharing
    Functions can be utilized by multiple scripts without copying, while maintaining a single source point for the common code.

  • Automatic dependency checking
    Scripts that share common code are automatically recompiled when that code changes, keeping them up-to-date.

  • Revision control
    Previous versions of code are directly available, as backups in case of errors or simply to "freeze" the code base for a given script.

  • Advisory locks
    A module can be locked to let others know that changes are in progress, helping prevent revision clashes.
These features are provided transparently to the user, without the clunky prototyping or hand-edited dependency checking common to other languages.

Overview

A Vortex module is a script that is stored in the library and whose functions are callable by other scripts. The library is composed of the SQL tables SYSLIB and SYSDEP in the default database, which are automatically created as needed.

Every module has a name, by which other scripts can include it, and one or more dated revisions. New revisions of modules are inserted into the library by checking them in (the -ci command-line option). The source code can be retrieved for modification by checking out the module (the -co option). A module's functions are included in a script for use with the <USES> directive.

Back: Controlled Access Applications - Continued Next: Writing a Module
Copyright © 2024 Thunderstone Software LLC. All rights reserved.