From: alexander s. <al...@an...> - 2004-07-27 05:53:31
|
Richard Jones wrote, at 27.07.2004 8:03: >> right. perhaps we should publish a class for generic config objects? >> >> i mean, remove core-specific functions (logging initialization, >> pyconfig loading and maybe TRACKER_HOME magic) from the base Config >> class and create separate CoreConfig class to hold all these functions. >> >> the Config class than would require configuration layout definition in >> constructor arguments and shall be usable to handle custom .ini files, >> e.g. roundup-server.ini > > This is a good idea. > > How do you envisage the following happening in a custom tracker template: > > 1. definition of the Config options > 2. invocation of the config reading i have two ideas: - users define configuration layout in __init__.py like we do in the configuration module. init is responsible for reading it's config file and attaching it to the core config. - detectors/extension configs have no predefined layout. configuration files for detectors and extensions have fixed name 'config.ini' and are processed either at the time of the main config loading or by Tracker.load_extensions(). options are created on the fly for all settings present in config.ini. the first approach is more flexible. the second one is more convenient, but does not support value conversion (booleans, numbers etc.) maybe we could have a mix of the two: lookup config layout definition in __init__ with fallback to autogenerated layout. > 3. access to the config from inside a detector core config has two additional attributes (and maybe items?) 'detectors' and 'ext', holding Config instances for detectors and extensions, respectively. sincerely yours, alex. |