[PEAK] runIni => ZConfig revisited

alexander smishlajev alex at ank-sia.com
Fri Nov 14 12:52:50 EST 2003


John Landahl wrote, at 14.11.2003 12:55:

> In re-reading the message at 
> <http://www.eby-sarna.com/pipermail/peak/2003-July/000589.html>, and 
> with the recently acquired knowledge of config.loadConfigFile(), it 
> occurred to me that one could have a key in a ZConfig-based config setup 
> a list of extra files for the application to load at startup.  Something 
> like this (untested):
> 
>    class MyApp(AbstractCommand):
>      configFiles = binding.Make(list)
> 
>      def __loadConfig(self):
>        for file in self.configFiles:
>          config.loadConfigFile(self, file)
>      __loadConfig = binding.Make(__loadConfig, uponAssembly=True)
> 
> The main (ZConfig-based) file might then look like:
> 
>    Config  foo-bar.ini
>    Config  more-options.ini
> 
> Does this seem reasonable?

not for us.  thanks for suggestion, anyway.

the problem with keeping two config files (ZConfig and .ini) instead of 
one is that two files are twice as difficult to maintain.  so we took 
the path that Phillip suggested: made a "root" component (not subclass 
of config_components.ConfigurationRoot; just a regular component 
instantiated by ZConfig schema), registering application-wide services 
like this:

     # registering our logger as a default logger
     _provider = lambda *args: self.logger
     self.registerProvider(PropertyName("peak.logs.*"), _provider)
     self.registerProvider(interfaces.ILogger, _provider)

(self.logger is set by ZConfig.)


by the way, if anyone interested: we made PEAK-based application, having 
several deployments yet, with core functionality now approaching it's 
beta stage.

the application serves as an interface to medical laboratory instruments 
(analyzers), getting measurement result data from these instruments and 
sending work orders to ones that support workorder upload.  the 
application is run as windows nt service.

unfortunately, we cannot open all of the application sources, but 
perhaps we could share some chunks of our code.  for example, we would 
be happy if our reactor is adopted to PEAK mainline.

we use ZConfig, bindings (of course!), pretty much of 'running' package, 
and fmtparse module to decode data from some instruments.

one of the biggest problems for us now is the requirement to restart the 
application upon any change in configuration file.  we have a strong 
need to reload config files on the fly, restarting or updating only 
those components that have their configuration changed.

best wishes,
alex.






More information about the PEAK mailing list