Jim Fulton wrote: > Have you written a ZConfig schema? Have you tried to read the > documentation on writing one? Have you writtem an application > that uses ZConfig? If you had, I think you'd know what I was > talking about.
I have. Our chunk of our schema.xml is over 600 lines including comments and whitespace and defines 22 sections. We needed a configuration mechanism for Launchpad and related tools. I decided to go with ZConfig to integrate our configuration with the rest of the Z3 configuration. This was with Zope 3.0 and integrating our config with the Z3 config was quite problematic. We gained a little doing it this way. Having the Z3 configuration with our own configuration information made is easy to maintain the multiple configs we need to maintain (several production configs and developer workstation configs, maintained in the RCS alongside the code). In theory, we could generate documented configuration templates but we haven't done that -- we just maintain the commends in 'default' configuration. We lost a fair bit of flexibility doing it this way. Field validation needs to be done the ZConfig way. There are issues with non-required fields in non-required sections giving us grief. There seem to be namespace issues, despite being hierarchical (eg. we have <librarian><librarian_server> instead of just <librarian><server>, it seems because <server> is already used by Z3 so we can't call our section that). These issues might be ZConfig in Z3.0 issues, or problems with how we are using it. If the issues we are having are our fault, I would also call that a problem with ZConfig as the documentation is not detailed enough to match ZConfigs complexity. Pulling in configuration information should be light weight, but I find ZConfig puts too much burden on developers for little gain. Despite being very complex, it seems to lack features that we need or the features don't work the way we need them too (eg. we really need to say 'this config file is identical to that one, except these fields are changed. Extending ZConfig to do this did not seem fun.). An alternative would have been a .ini or xml format similar to what you have already described. I elected to proceed with ZConfig to see how we went and to integrate our config with Zope3's. In hindsight, I think we would have had a simpler, more flexible and more easily extensible system if we had gone with .ini or xml instead. Migration for us shouldn't be a problem, we access to our configuration is via a simple API so we can replace the guts. I expect to reimplement our config machinery when I get a chance to work on low priority tasks (we have issues with what we have, but it works). 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. -- 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