Configuration 4 GNU (CFG)
|
|
Supporting Files | | |
|---|
Some files, such as Schemas, files which contain mapping
information, distro-specific information, etc. are used by more than
one layer and thus are mentioned here.
Remember that parsers are the "bottom layer" programs that
can generate XML representations of configuration data and
write or modify configuration files from the XML representations.
Parser definition files map a configuration identifier,
such as "samba", to the information needed to translate between
underlying configuration data and an XML representation of
the configuration data. This information includes:
translated names and descriptions of the
parser what back-end parser to run what parameters the parser understands
(e.g. location of configuration file, version of
application), their descriptions, and default
values how to communicate the values of parameters
to the parser
Schema files define the structure of XML configuration documents.
They define what elements are allowed where, and what the content
of each element is allowed to be. Elements can be defined as
"simple" or "complex." Simple elements contain text content only;
examples might include String, Number, Date, or Path.
Complex elements can contain child elements and/or text content.
In this case the schema would list what child elements are
expected.
Schema files declare a type for all elements it defines. Some
types (those that are considered fundamental) are defined by the
XML Schema specification or by Config4GNU. Other types are defined
by the XML Schema file they are referenced in.
For the purposes of the Config4GNU system, type definitions will
need to define how an element of this type can be displayed and
edited in the front-ends. This will require the following bits
of information:
A unique identifier for the type. For starters,
this will simply be the filename of the type definition
file. This way, given the unique identifier, accessing
the type is easy. In the future, this may be converted
to a full-blown URI method, and a database will need
to be maintained to map the unique identifiers to the
actual files that contain their information.
Name and description of the type, for use in front-ends.
The name and description will be localized by
translators so a user will see this in their native
language.
A list of allowed properties. See
Property Definitions below.
Methods that are available on the object. There are two
types of methods: new methods and methods that override
built-in methods. New methods provide a feature that
existing methods cannot do, such as start/stop/restart
a service. Overriding built-in methods would override
certain default methods, such as methods for "getting"
and "setting" properties. For instance, you may want to
override the "name" and "children" properties.
For normal objects, a list of "forms" that
can be used to edit this element. For primitive objects, what widget to display.
If the widget is unavailable on the specific
platform that is being used (i.e. Web vs. Gtk+),
there must be a way to fall-back to a less-specific
but more flexible widget, e.g. text entry.
Property definitions are contained within type definitions.
They contain the following attributes for each property they
are defining:
Element/attribute name Localized name and description Default value "Type" of property (i.e. what type definition
is used for this property) Minimum/maximum cardinality
| |
|
|
|
|