|
| 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.
|