Progress Programming Tips

PPT-29  Special validation lists

Tip:

During the design and initial development phases it is common to
identify sets of valid values for special data elements.  The kind of
validation lists I'm talking about are not the typical lookup or
translation lists such as a state table but rather the list of valid
statuses, or types that are used to control processing.  In most of
these cases the size of the set is small and the application will be
making logic decisions based on the values.  To summarize some set
options -

1.  Relation based lookup table (States)

Used to store a medium to large number of entries.

Often translates an integer based representation or short code to a
full description or additional detail.

Is often maintained by the user or from an external data source.

Values used in searches, and qualifications but rarely in the source
code logic itself.

2.  Limited typing information (Names of the Months)

Used for small sets of known values.

Not worth a dedicated table, but requires standardization support.

3.  Control or status information (Open, Closed, Pending, ...)

Used for small sets of known values.

Probably not worth a dedicated table.

Requires standardization and flexibility in modification/expansion.


When using a set of type 2 or 3 several non table options can be
used to provide the standardization and the ease of modification etc.

1.  Use a standard internal procedure to return the list and or
validate an entry against.  This procedure could be in a persistent
library or included via an include in those instances requiring the
support.

2.  Define a preprocessor list or a variable with the list values but
again, probably best managed in an include file for each instance
requiring the support.

3.  Use a single "generic" table to store these kind of lists and
populate a variable upon initialization for those that need the data.
Or again, provide a standard internal procedure and the storage method
can be changed at will.

4.  Use an .ini key value entry to make the list accessible from
both inside the application and out.

For options 3 & 4 above you have the flexibility of renaming the
various values.  If this is an important customization requirement
then be sure to code the logic based on position rather than the
string.  While not typical, this flexibility can be important in some
situations.  If it is though you probably need both an external
representation of values (for editing) and an associated internal
value to code logic to.  Think of the internal values as your API to
what the application can respond to.

A step beyond providing standard management of control values is to
also organize your programming logic in such a way that not only the
list of values can be managed easily but that the logic using those
values is well enough encapsulated to replace without affecting large
portions of the application.  This is considerably harder to do though
in many applications it is worth the effort.

Wisdom:

A little extra planning and design can go a long way towards dealing
with the dynamic requirements often forced upon development at the
last minute.

Rod Gaither                  | rdg@worldinfo.com
World Information Systems    | (910) 333-2580  Voice
Greensboro, NC               | (910) 333-2584  Fax