Chris Withers wrote: > Stuart Bishop wrote: >> the Z3 configuration. This was with Zope 3.0 and integrating our >> config with >> the Z3 config was quite problematic. > > What were the problematic bits?
# Disgusting hack to use our extended config file schema rather than the # Z3 one. TODO: Add command line options or other to Z3 to enable overriding # this -- StuartBishop 20050406 from zdaemon.zdoptions import ZDOptions ZDOptions.schemafile = os.path.abspath(os.path.join( os.path.dirname(__file__), 'lib', 'canonical', 'config', 'schema.xml')) Also, there is only one schema.xml so multiple components can't each insert their own blob of configuration information into the global schema. >> We lost a fair bit of flexibility doing it this way. Field validation >> needs >> to be done the ZConfig way. > > How would you prefer to do it? Validation of the entire config file, and if there are one or more errors output a readable report at the end with error messages returned by the validators. The current mechanism just spits out exceptions, which is really bad for configuration files aimed at end users. >> There are issues with non-required fields in >> non-required sections giving us grief. > > Can you describe these a little? If I have a non-required section foo, containing a non-required key bar, if I try and access config.foo.bar I get an AttributeError. I should get the default value for bar. This causes noise in our config files and a maintenance burden where we have to include non-required sections just so the default values of keys will be accessible. >> So +1 I guess. Although I personally would prefer using XML, as I >> think it >> will be more readable for complex configurations as it is better able to >> represent heirarchies and provide more flexibility to developers. > > My main gripe with the .ini format is the lack of hierarchy, but then I > worry that with XML we'll suffer from an overly complex schema... Why would you want a schema for the XML? - The config file could just be arbitrary well formed XML. - validation handlers would be registered for a particular XML namespace - Config file is loaded into a set of data structures, one for each XML namespace - warnings are emitted if there are XML namespaces loaded that don't have a validator. - validators are called, giving them a chance validate and convert values to native types. They are allowed to raise an error if they find stuff they don't know about lurking in their namespace. - the resulting datastructures are available via a thread global For sane config data, I don't think the sucky bits of XML need to be worried about. It is pretty unlikely that you need to include <> or & symbols or wierd Unicode hieroglyphs in your configuration data (but if you do, at least you already know how to insert it because we all know enough XML now to do this). Of course, .ini would be able to emit more meaningfull error messages: foo/bar/1 in section [whatever] is required, but not found blah/whatever in section [whatever] is not a valid url section [baz] is required but does not exist. -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/
Description: OpenPGP digital signature
_______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com