Jim Fulton wrote:
Finally, I'll note that I've used the term "high-level configuration" to
refer to the things we have sysadmins edit when they install Zope
systems. We currently use ZConfig for this. I don't think ZCML
(or any other XML-based system) should be used for this.
Ok. The high-level configuration I'm thinking about is somewhere in
between. I don't know what to call it, so I won't call it anything.
Here's what has happened to me several times: I'm a Python developer,
writing simple code for Zope 3, and I follow Stephan's examples on how
to develop content types for Zope 3. I write simple schema-based
classes and simple directives. I've been conditioned to not repeat
myself in code; in fact, breaking that rule gives me a sick feeling. So
I proceed to follow Stephan's examples, which involves writing similar
ZCML directives for multiple classes. The repetitious classes don't
bother me because I know how to refactor them. But the ZCML I've
written gives me a sick feeling, because I don't know how to refactor
ZCML. The sick feeling doesn't go away, so I get scared of Zope 3.
Then I come here, hoping to find comfort.
I would feel more comfortable if one of the following things were to happen:
1. The group acknowledges that repetition in ZCML is bad.
2. Someone shows me how to avoid repetition in ZCML.
3. We decide that ZCML is a failed experiment.
4. We decide that ZCML should gain more qualities of a high level language.
5. We solve this some other way.
I recognize that #3 and #4 are very risky, and we've already been over
the risks, but I include them because they still feel better than the
I can't help but wonder if ZCML is largely a reaction to the horrible
initialize(context) methods in CMF products. Those beasts are horrible
because they are based on workarounds of workarounds. The workarounds
came about because we were more willing to add code than fix code. That
attitude prevailed because we didn't have automated tests of Zope.
Now that we have automated tests, programmers are more likely to fix
code rather than add code, so we can expect to see very few workarounds,
so initialize(context) garbage won't happen.
Zope3-dev mailing list