|
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.
Copyright © Thunderstone Software Last updated: Mon Feb 18 10:28:15 EST 2013
|