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 status quo.

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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to