Configuration 4 GNU (CFG)
|
|
CFG Upper Layer | | |
|---|
The upper layer of CFG provides an interface to the CFG system.
Unless circumvented manually, it handles ALL
configuration specific actions required to load and save a virtual
CFG XML document.
Authorization & Authentication
Before accessing the configuration data, a client must select an
Authority. The selected authority will
determine what level of access the user will have to the
configuration. How the client obtains an authority depends on
what type of application it is. If it is a normal application,
running as the user, the default authority will be an object
representing the current user. If the client is running as a
system user, e.g. apache, it will want to
obtain an authority representing the user that is using the
program.
CfgAuthority::get_initial_authority() will
return an authority representing the user ID of the current
process. A program that the user starts will want to use this
method because the user has already authenticated.
CfgAuthority::get_local_user(username) will
return an authority representing the user specified with the
username argument. Programs that are running as a system user
will use this method after obtaining a username from the
user. Once receiving the authority object, the client will
need to authenticate to make it valid.
Once an authority object is obtained, it may need to be
authenticated. Simply call the authenticate
method, passing it the user's password (or whatever
credentials required by the authority).
Finally, when an authenticated authority is in possession,
the client can use the get_configuration_root
method to get a reference to the configuration tree.
The Configuration Interface provides the API for
accessing and modifying configuration data. The following several
sections will describe the various classes and
functions that are available to them.
CfgObject is a class
that provides an interface to a node in the configuration tree.
It can be considered a simple wrapper to an XML
Node, but it provides several
features not found in the XML DOM API. These features include
functions particular to the configuration domain of Config4GNU.
These features are:
Signals for when the structure and contents
of the object are changed. Access to object and property type
information. Automatic loading and saving of XML as
needed. Dynamic merging of multiple XML
documents to present a single hierarchy of
configuration.
Signals allow parts of a program
to register themselves as listeners for
certain events, such as "value changed" or "property added".
Whenever the CfgObject class is used
to make a change to the object, it will automatically "emit"
the appropriate signals, and this way any listeners to that
event will be notified. An example of this is a text entry
control that automatically updates its contents whenever the
object it is bound to is updated.
The CfgObject also automatically handles
objects that import other configuration
documents. For example, consider the following fragment of
config4gnu.xml.
| Example 6. An Import Object | <application>
<name>Samba Configuration</name>
<module>CFGXML::Parser::App::Samba::Common::SambaParser</module>
<configfile>/etc/samba/smb.conf</configfile>
</application> |
The object represented by the application tag
here is an "import" object. When double-clicked in the GUI, the
Config4GNU system will run the parser specified by the
module tag using the file specified by the
configfile tag and the XML representation
generated by the parser will be inserted as if it were in the
application element.
| |
|
|
|
|