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 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 files. When looking at ZCML we should clearly keep in mind that what it replaces. Silva's 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

Reply via email to