ZConfig and other formats for ZCML

Author

Status

Problem

As a format, ZConfig has been very popular. It is less intimidating that ZCML. It is also very useful to be able to easily specify alternate high-level configuration files via a command-line option (-C) and to be able to override individual options using the -X command line option.

Unfortunately, it's far too difficult to add new configuration options to ZConfig. It's also inconvenient to access the data. Data are returned in an options object returned by the parser. The main program has to distribute the data to the various parts of the application that need it. (A simple improvement would be to register this object as a utility, so that it could be accessed by application code as needed.)

It's also problematic to maintain 2 configuration systems for Zope, ZConfig and ZCML.

Some people feel that using XML for configuration is too cumbersome. They would like to use different formats. Making the input format more flexible would allow experimentation with different formats.

Proposal

Extend ZCML to allow alternate input formats. In meta.zcml files, you could register a new input format, specifying a format and a parser:

    <meta:format id="ZConfig" parser="zope.configure.zconfig.Parser" />

Then, when using include, you could specify the format to be used:

In ZConfig's case, we'd likely introduce a specialized include directive that would respect the -C command-line option. Or possibly, the parser would handle that. It's worth noting though, that it would often be useful to separate the configuration file to address separate concerns such as server, database, and application configuration.

Perhaps it would be possible to allow a command-line option to be specified as an include option:

A parser object would take a file name and produce an iterable of sax events. (The ZConfig parser would use -X options to affect the data.)

Data will be handled using the well-defined and flexible ZCML handler framework.

For ZConfig, a IZConfigOptions? interface will be defined to represent the ZConfig options object. We'll register the options object as a utility. To the extent that we want to keep using an object like that, option handlers would save their data in this object. Application code would access data through this utility. IMO, this will improve access to option data and should be done even if we decoded not to implement this proposal.

Risks

Existing ZConfig schema and component definitions will have to be rewritten as ZCML definitions. It is possible we could create tools to convert existing ZConfig component definitions to ZCML meta configuration files and handlers, although I'm not sure it's worth it, as I don't think there are that many components to be converted.

Application access to ZConfig-defined data will change. The change would be quite minor, as only an additional utility look-up call would be needed to be added to existing code.

Implementation Status

Not implemented.

I expect that this would be implemented for Zope 3 first and, if successful, would be used in Zope 2 later.