--On 5. März 2006 13:56:38 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:
The right way would be to refactor ZConfig and decouple it in a reasonable way from its dependencies.I think this would be a major rewrite.
Possibly but I don't consider that to be a strong argument for introducing a weaker mechanism.>
They have to deal with it now, but now it's really hard. I think that a simpler approach would allow much simpler configuration support. To extend ZConfig now, you have to create XML schema descriptions, and have deep knowledge of how ZConfig works. Why do you think it's better to have to create a monolithic schema for all applications bits that want to use the configuration file, rather than letting individual applications define how to read their own data independently?
A monolithic schema is of course a problem. I am sure it could be solved by refactoring ZConfig.
There could still be frameworks to make handling configuration data easier.
I agree but I really dislike the idea of flattening a hierarchical structure into a INI-like format. Having /x/y/z as section names looks both funny and somewhat unprofessional. The format looks as if would have been invented by a first grader. There is no question that ZConfig has the problems you described. But I consider such a flat representation as poor and a step back instead of a step forward (independent of the effort needed to simply and refactor ZConfig).
Description: PGP signature
_______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com