Shane Hathaway wrote:
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
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
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
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.
Zope3-dev mailing list