--On 5. März 2006 14:43:48 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:
> There is no question that ZConfig has theproblems 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.
Let's try to approach from the other side. We both agree at ZConfig sucks at some point. We need something else. The "something else" should be provide
a similar functionality as ZConfig: - some support for hierarchies - schema-based - validation - default values - local configurations, no global schemaIn the first place such a framework would be independent of any input format. A ZConfig-style parser or a .INI parser could use such a framework to make configuration information available through a unique API. So the basic "problem" of this whole issue is how such a framework would look like, how a schema-definition would look like etc. Writing a parser that adopts a particular input format to the abstract configuration framework is at best an engineering challenge and the decision to use a ZConfig-style or an INI-Style configuration file format as default is like a personal preference for beer or wine (beer for the mass, wine for the power users :-))
Description: PGP signature
_______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com