Andreas Jung wrote:
--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.>
I don't think that the complexity of ZConfig is justified by the power of
They have to deal with it now, but now it's really hard. I think that a
approach would allow much simpler configuration support. To extend
you have to create XML schema descriptions, and have deep knowledge of
Why do you think it's better to have to create a monolithic schema for
applications bits that want to use the configuration file, rather than
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.
Yes. That's why I tried to propose reimplementing ZConfig on top of the
ZCML engine a few weeks ago. If that was the only goal, then I think
this would be the way to go.
There could still be frameworks to make handling configuration data
I agree but I really dislike the idea of flattening a hierarchical
into a INI-like format. Having /x/y/z as section names looks both funny
and somewhat unprofessional.
Obvoiously, this is a matter of taste. Many people are put off by even
the hint of XML in ZConfig.
> The format looks as if would have been
invented by a first grader.
It probably was. ;)
> 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).
I agree, however, I think that there are other benefits of a move to
ConfigParser that far outweigh this disadvantage.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list