[Zope3-dev] what is ZCML?

Shane Hathaway shane at hathawaymix.org
Wed Mar 15 16:00:06 EST 2006


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.

Shane


More information about the Zope3-dev mailing list