Vortex Library Modules

When creating a complex Vortex application, keeping the code in one large script can be unwieldy. 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.

Library modules help solve these problems. Modules provide the following features to Vortex:

• Modularity. Code for a script 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.

• Dependency checks. 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.

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.