[Gnumed-devel] Gnumed config editor

[Hilmar Berger]

Hi,

I had a look at the ConfigEditor in test-area/shilbert (Thanks Sebastian.)
I couldn't get it up and running,though, but at least got some impression
on how it should eventually look like.

The current implementation is limited to the the config options present in
gnumed-archive. It is designed as notebook of panels where each page
represents the options belonging to one particular problem (import/export,
scan options, backend config etc.).
It does basic validity checks on the data entered.
IMHO this concept (single pages for related options,validity checks)
represents the highest level of convenience to the end user. Eventually we
should have a config module that has that functionality.
However, coding every single config item by hand imposes a relatively
hight cost. Every change of config options in some other module has to be
reflected in the code. Right now the gmConfigEditor.py is about 50k,
adding all config options to come will certainly blow that up to about
200k.

I therefore suggest that we generalize the implementation a little bit,
allowing for easier updates of config parameters and for other types of
data representation to the user.

My suggestions are:
1. order all config parameters in some type of hierarchy. This could
either be implemented by naming conventions (e.g. module.group.parameter)
or by passing a group name in addition to the parameter name (this could
be implemented using the 'cookie' entry in gmCfg)
Reason: allow for automatical grouping of paramers, make parameter names
more informative

2. create a config parameter definition dictionary that can be read from a
file/DB. Definitions would at least contain name/group, type, valid
values and description (later maybe constraints, too).
The dictionary will be versioned in order to get a valid match.

3. handle config parameter definitions and actual config data stored in
the backend by a higher level (business-object like) config data object.
This will talk to the backend via gmCfg and provide functions for entry
validation and parameter grouping.

4. as a temporary solution, implement a config-GUI resembling the
'regedit' Windows registration editor on top of the config object .
Reason: quick solution, sufficient for development, allmost the complete
structure of the gui can be derived from the config parameter definitions.

5. as a final step, implement a notebook like config option widget as
suggested by Sebastians first implementation. This should use the same
underlying configuration object. All we will have to add is the
information on how to align the parameters on a notebook page.

The above is not considered highest priority, given the fact that Karsten
and Sebastian will absent for some time. Nevertheless I would appreciate
any comments.

Hilmar