Configuration 4 GNU (CFG)

The user interface is a specific UI (GUI, Web, Command-line, etc.) which calls library functions to perform any real work to read and manipulate XML files. This common library will be used by all UIs to perform XML editing tasks. The UIs will be generic, extendible tree and form based XML editors which will happen to have lots of configuration-XML editing extensions supplied with it. The library functions needed to perform XML tasks not specific to configuration will be included with the generic XML library, separate from the main CFG library so that it will be possible to use the UIs for editing other XML documents without loading the main CFG library.

The UI loads one XML document via library calls. This document may contain links to other XML documents. These links will allow entire documents to be logically attached to XML nodes of the parent document to facilitate editing.

The actual UI itself will contain no configuration specific code, nor will it contain code to directly manipulate XML. All this will be handled by library calls so multiple UIs can easily be built.

When an XML representation of configuration is loaded into the client, it will be loaded from some base, called the Root Node. This root node could be the root of just one aspect of configuration, such as Samba if you only want to edit Samba's configuration, or more commonly it would be the root node of the local computer, showing all the configuration available on the computer. A third case for a root node would be a node representing the base for all the computers in an organization.

To change whatever the current root node is, look for an "open" feature in the front-end. This "open" command will allow you to specify what aspect of configuration you want to load, and that aspect's root will become the current root.

The current root will be displayed as the root of the "object tree."

Many user interfaces will support the metaphor of an "object tree," to allow easy access to the various sections of a configuration file. An example of the object tree is shown in the left pane of the above screenshot (the Gtk+ client).

The object tree is constructed by starting with whatever the current "root" node is. Any element of any XML document may be a root node, but it will most commonly be the root node of some aspect of configuration, a node representing all the configuration available on a single computer, or a node representing all the configuration available on all the computers in an organization.

For every element that appears in the object tree (starting with the root node), its name will be displayed. The name of an object is defined by the object type, but is usually simply the content of the name property (see Object Names).

Also for every element appearing in the object tree, one or more children may appear. The children of an element can be defined in multiple ways depending on what type of node it is (see Object Children). In this manner, many of the "objects" found in an XML document can be selected.

Using the object tree, a user can select a node to edit by clicking on the respective item in the object tree. When an object is selected, forms appropriate for editing the object are loaded in the right pane.

Forms give users a window filled with widgets and labels of various types where users can see the important properties of an object and edit it using text boxes, list boxes, buttons, and other common controls. The information is presented in an organized way and may be split into multiple tabs or pages if there is a lot of data to present.

Forms are defined using an implementation-independent language, such as XForms. The same form definition files could be used to create Gtk+ dialog boxes and HTML web pages. Forms for some aspect of configuration are distributed with the program that they are meant to configure, by Config4GNU itself, or some third-party. As new versions of a particular distribution or system application are released, the forms may need to be updated to support new features.

The property list is a default form that is available for all "normal objects". It is a form that displays a list of all properties and their values. The list will have two columns. In the first column are the names of the properties, and in the second column are the respective values. When you click on a value (assuming you have permission to edit it), depending on the type of data it contains, the cell will be replaced by an inline editable widget, or another screen will appear allowing you to edit the property.

Primitive objects will typically have a simple widget defined to display its value and allow the user to manipulate it. For example, an element which specifies a path may have a Browse button next to it which allows the user to select a directory on their file system to use as the value. In an SVG document, perhaps a color element would have a color wheel widget to allow the user to select a RGB color value and see a sample of it in real time. This is done in the XML Schema by defining precisely what data type an element should have. Then the front-ends use their knowledge of the various data types to select the appropriate widget.

Validation on the user interface level is the first stage of validation when a user uses Config4GNU to make a change to configuration. Validation on this level is validation on a "widget" level. For example, a widget for entering a date will ensure that the value entered is in a date format and corresponds to an actual date.

Validation will continue in the lower layers as the user-initiated change in configuration trickles down to those layers.

The user interface layer must also be ready to handle data already in the configuration file that does not appear to be valid. Continuing the example above, the date found in the native configuration file is not a valid date according to the widget used to display/edit the date in the user interface. In this case, the user interface should probably accomodate by using a less restrictive widget for displaying/gathering the data (e.g. a simple text entry).

The library shared by all UIs to perform tasks not restricted solely to each UI (such as handling mouse clicks in a GUI, generating HTML in a web-based version, etc). The UIs will process the user input and handle the rendering of the UI, and then use functions in this library to do the real work.