An Application Configuration Utility

Note - See Configuration Revisited for details of a newer version using WPF rather than APL/W native controls.

Finding myself in the situation of building a series of (content-unrelated) applications a question that emerges is how to best (in the sense of minimising my effort) to handle common functionality.  There's a bigger question here about general utilities, and that's covered elsewhere.

The issue at hand here is application configuration; the starting set of assumptions when the application starts up, how these might be changed, and how to store the state of the application at shutdown.

The approach used is based on Dyalog APL/W, making fundamental use of namespaces - and (for this reason) hasn't been migrated to any other APL implementation.  Code is available on a no-fee, no-support basis from Dogon Research.

Goals

Methods

There might be other possible methods, but I haven't explored them.

Solution Implemented

Configuration values are held as components in an APL component file, typically called config.

Each component is a four-element vector, where the elements are:

Here's an example...

#.UTILS.TOOLS.displays Œfread 33 19
.…-4---------------------------------------------------------------.
| .…-3--------. .…-17-------------. .…-19---------------. .…-6---. |
| |255 255 128| |#.GLOBALS.colBack| |Barchart Background| |Colour| |
| '~----------' '-----------------' '-------------------' '------' |
'-----------------------------------------------------------------'

At present the types available are:

The overall architecture allows new types to be added as required (and changes to behaviour for existing types percolates automatically across applications).

The configuration file may hold other data in other components 

Application Startup

A single line is required as the application starts...

GetConfig(#.GLOBALS.homefolder,'config')(12 13 14 17 19 20 21 22 23)

Arguments are the configuration filename and a list of components.

GetConfig is itself straightforward and is unchanged whatever the application...

GetConfig w;ŒIO;ŒML;file;comps;config;citem
Get configuration globals
ŒIO ŒML„0 3
file comps„w
config„file ReadConfig comps
:For citem :In config
:Select 3œcitem
:CaseList 'Bool' 'Colour' 'Date' 'Num'
–(1œcitem),'„',(•†citem),''
:CaseList 'Char' 'Drive' 'File' 'Folder' 'Printer'
–(1œcitem),'„''',(†citem),''''
:Case 'CharMat'
–(1œcitem),'„†citem'
:Else

:EndSelect
:EndFor

All it does is read components from the file and create the appropriate global (as new types are added it will change, but these changes will migrate automatically into all applications which use the configuration utility).

Changing Configuration Values

Within an application it's useful (and often necessary) to view and edit configuration values.

Putting a line like this into the menu creation for the main form does what's needed...

'Config'ŒWC'MenuItem' '&Configure...'('Event' 'onSelect' '#.EXIF.FORM.Configure'((#.GLOBALS.homefolder,'config')(12 13 14 17 19 20 21 22 23)))

When the menu item is selected the configuration utility code builds an appropriate modal form...

Each 'row' on the form corresponds to a configuration item (the 'Bool' type is mapped onto radio buttons because it seemed more appropriate in an either/or context and to cater for an extension into multiple choices, otherwise the type/GUI mapping should be non-contentious.

Everything to do with handling thus form is held within a single namespace and doesn't change across application.

There's nothing sinister under the hood of Configure, each application may have some specific requirements which are coded there, but the main purpose is to run the line

opt #.UTILS.CONFIG.Configure msg

Which creates the modal subform as a child of the main form and awaits events.

Summing Up

This utility has reduced the effort of adding (and/or changing) configuration options to an application to two lines of code - when new configuration items are added only the list of configuration components needs to change (and the component needs to be added to the configuration file).

The utility is easily amendable so that new types of configuration value can be added at will.  In the context of application utilities these extensions are made automatically available to all applications which use this framework.

Code is available (free of charge for non-commercial use) for Dyalog APL/W Version 10 and higher from Dogon Research.

If you want to know more, please contact Dogon Research.


Copyright Dogon Research 2005-2010; Latest Update: 24 August 2010