[Zope3-dev] what is ZCML?

[Martijn Faassen]

Shane Hathaway wrote:
[snip]
> 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 share these sentiments. Not that I have a particularly sick feeling 
(I've been immunized by too much exposure? :) but because I'm grasping 
for ways, patterns, to make my code look better, briefer, shorter, less 
repetition, more reuability.

> I would feel more comfortable if one of the following things were to 
> happen:
> 
> 1. The group acknowledges that repetition in ZCML is bad.

I definitely acknowledge his one.

> 2. Someone shows me how to avoid repetition in ZCML.

Grasping around here myself. We need to show more people than just Shane 
and Martijn too - we need to be able to reach a wider audience if this 
is going to work.

> 3. We decide that ZCML is a failed experiment.

On the one hand, I'm not willing to do that. On the other hand, if ZCML 
is to be a simple registration language, I am starting to idly wonder 
why a bunch of CSV tables wouldn't do (and might not be clearer and 
simpler).

If ZCML is to be a simple registration language, I'd also like there to 
be a 1 to 1 mapping of ZCML statement to Python code. Right now there is 
a mapping and while it may be reasonably straightforward, I personally 
am still lost in APIs (and it looks like Jeff Shell is too). This 
learning curve should be smaller.

Whatever we do, if ZCML is to be replaced we need to replace it with 
something. I think many of the notions of ZCML are dead on - this 
registration shouldn't be happening in normal Python code mixed with the 
rest but as a separate activity. It should allow overriding. It should 
be amenable to analysis.

> 4. We decide that ZCML should gain more qualities of a high level language.

I personally am quite interested in exploring this, but I'd like to see 
some examples of what this would actually look like, concretely.

> 5. We solve this some other way.

This would be satisfactory too. :)

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

We can mitigate some of the risks of both #3 and #4 as we could do them 
as separate, experimental, non-Zope projects.

> I can't help but wonder if ZCML is largely a reaction to the horrible 
> initialize(context) methods in CMF products. 

In non-CMF Silva we also got horrible initialize(context) methods, and 
we've got horrible and long install.py files. When looking at ZCML we 
should clearly keep in mind that what it replaces. Silva's install.py 
expressed in ZCML would be preferrable to what we have now in most ways.

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

And because we weren't as good at designing good Pythonic APIs as we are 
now. At least I've definitely gotten better at that over the last years.

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

I'm not convinced of this, myself. If Zope 3 becomes popular, lots of 
application developers won't be using automated tests in Zope 3 code 
either. In addition, you get unnecessary workarounds because people fail 
to see the right way to do it and are in a hurry. I feel that a 
declarative and domain specific language can help in such cases.

Regards,

Martijn